This discussion is archived
1 2 3 Previous Next 34 Replies Latest reply: Jul 1, 2011 4:05 PM by jschellSomeoneStoleMyAlias RSS

Why does Exception allows Throwable as a cause

864321 Newbie
Currently Being Moderated
I was wondering why Exception class allows Throwable (which includes Error's) to be a cause of an Exception.

Error's are never meant to be handles (because they are considered unrecoverable) and Exceptions can be handled. So why allows an Error to be the cause of an exception?

A business scenario where this could be useful perhaps?
  • 1. Re: Why does Exception allows Throwable as a cause
    jtahlborn Expert
    Currently Being Moderated
    because sometimes you do want to catch everything. one example is when you want to transfer failures from one thread context to another, e.g. FutureTask. FutureTask catches Throwable within its run() method. that Throwable is then transferred to the context of another thread by being thrown, wrapped as an ExecutionException, to the caller of the FutureTask.get() method.
  • 2. Re: Why does Exception allows Throwable as a cause
    796440 Guru
    Currently Being Moderated
    yogesh wrote:
    I was wondering why Exception class allows Throwable (which includes Error's) to be a cause of an Exception.
    Why wouldn't it?
    Error's are never meant to be handles (because they are considered unrecoverable)
    They are rarely meant to be handled, not "never." Handling them or not is a design decision, not a language syntax issue.
    A business scenario where this could be useful perhaps?
    An app server is managing several applications. One of them throws OutOfMemoryError. The app server catches it and shuts the offending app down as gracefully as possible, without disturbing the other apps.
  • 3. Re: Why does Exception allows Throwable as a cause
    jtahlborn Expert
    Currently Being Moderated
    jverd wrote:
    yogesh wrote:
    A business scenario where this could be useful perhaps?
    An app server is managing several applications. One of them throws OutOfMemoryError. The app server catches it and shuts the offending app down as gracefully as possible, without disturbing the other apps.
    actually, that's a bad example. the code in which an OutOfMemoryError is thrown may or may not be the offending code. it could just be the straw that broke the camels back. OutOfMemoryErrors are rarely recoverable since they can leave the jvm in a bad state.
  • 4. Re: Why does Exception allows Throwable as a cause
    796440 Guru
    Currently Being Moderated
    jtahlborn wrote:
    jverd wrote:
    yogesh wrote:
    A business scenario where this could be useful perhaps?
    An app server is managing several applications. One of them throws OutOfMemoryError. The app server catches it and shuts the offending app down as gracefully as possible, without disturbing the other apps.
    actually, that's a bad example. the code in which an OutOfMemoryError is thrown may or may not be the offending code. it could just be the straw that broke the camels back.
    True. But nonetheless, that app is already dead, but that doesn't mean we have to kill the rest of the apps and the server.
    OutOfMemoryErrors are rarely recoverable since they can leave the jvm in a bad state.
    As far as I know, the OOME itself can't corrupt the JVM, though ignoring it can certainly corrupt your app. It still makes sense for the app server to make a best effort at recovery, and if it's not possible, you're no worse off.
  • 5. Re: Why does Exception allows Throwable as a cause
    jtahlborn Expert
    Currently Being Moderated
    jverd wrote:
    jtahlborn wrote:
    jverd wrote:
    yogesh wrote:
    A business scenario where this could be useful perhaps?
    An app server is managing several applications. One of them throws OutOfMemoryError. The app server catches it and shuts the offending app down as gracefully as possible, without disturbing the other apps.
    actually, that's a bad example. the code in which an OutOfMemoryError is thrown may or may not be the offending code. it could just be the straw that broke the camels back.
    True. But nonetheless, that app is already dead, but that doesn't mean we have to kill the rest of the apps and the server.
    OutOfMemoryErrors are rarely recoverable since they can leave the jvm in a bad state.
    As far as I know, the OOME itself can't corrupt the JVM, though ignoring it can certainly corrupt your app. It still makes sense for the app server to make a best effort at recovery, and if it's not possible, you're no worse off.
    the OOME can be thrown for any object allocation. this includes both "app" object allocations and jvm internal object allocations (for jvm state management). you have no way of knowing what got left in a bad state when the OOME was thrown. unless you are using some sort of transactional memory based jvm where all the work that was done on the thread is rolled back in the event of an exception, your jvm is probably borked.

    Edited by: jtahlborn on Jun 29, 2011 1:49 PM
  • 6. Re: Why does Exception allows Throwable as a cause
    796440 Guru
    Currently Being Moderated
    jtahlborn wrote:
    the OOME can be thrown for any object allocation. this includes both "app" object allocations and jvm internal object allocations (for jvm state management).
    I wasn't aware of that, and OOME's docs only say: "Thrown when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector."

    Do you have a reference to support that? If so, then I amend my example above to, "An app throws any other Error +except+ OOME..." And if this is the case, then anywhere that catches Error should first catch OOME and rethrow it, since whatever recovery is done for Error in general is unlikely to succeed for OOME.
  • 7. Re: Why does Exception allows Throwable as a cause
    jtahlborn Expert
    Currently Being Moderated
    jverd wrote:
    Do you have a reference to support that? If so, then I amend my example above to, "An app throws any other Error +except+ OOME..." And if this is the case, then anywhere that catches Error should first catch OOME and rethrow it, since whatever recovery is done for Error in general is unlikely to succeed for OOME.
    what reference do you need? open up Class.java or ClassLoader.java. what is going to happen if an OOME gets thrown half way through loading some new classes or a new classloader? i would imagine the jdk implementors attempt to make that code somewhat safe, but i highly doubt is is 100% impervious to a random OOME. and if a class or classloader is in a bad state, i can't imagine that your application is going to continue happily along.
  • 8. Re: Why does Exception allows Throwable as a cause
    796440 Guru
    Currently Being Moderated
    jtahlborn wrote:
    jverd wrote:
    Do you have a reference to support that? If so, then I amend my example above to, "An app throws any other Error +except+ OOME..." And if this is the case, then anywhere that catches Error should first catch OOME and rethrow it, since whatever recovery is done for Error in general is unlikely to succeed for OOME.
    what reference do you need?
    I'm just asking for something that definitely says it can muck up the JVM internals. The javadocs don't make that clear.
    open up Class.java or ClassLoader.java. what is going to happen if an OOME gets thrown half way through loading some new classes or a new classloader?
    Presumably the class doesn't get loaded, and unless I see documentation otherwise, I assume the JVM is still fine, unless of course that class happened to be one that the JVM needs to run, like String. I'm assuming (though I could be wrong--but won't believe I am without appropriate support) that, just as my OS can prevent a malloc in my app from screwing up the OS other apps, so can the JVM prevent an OOME from screwing up the JVM itself.

    Sure the JVM may not be able to allocate enough memory to do its job, but when that happens, I expect it to dump core, rather than returning control to my app via an OOME.
  • 9. Re: Why does Exception allows Throwable as a cause
    jtahlborn Expert
    Currently Being Moderated
    jverd wrote:
    jtahlborn wrote:
    jverd wrote:
    Do you have a reference to support that? If so, then I amend my example above to, "An app throws any other Error +except+ OOME..." And if this is the case, then anywhere that catches Error should first catch OOME and rethrow it, since whatever recovery is done for Error in general is unlikely to succeed for OOME.
    what reference do you need?
    I'm just asking for something that definitely says it can muck up the JVM internals. The javadocs don't make that clear.
    open up Class.java or ClassLoader.java. what is going to happen if an OOME gets thrown half way through loading some new classes or a new classloader?
    Presumably the class doesn't get loaded, and unless I see documentation otherwise, I assume the JVM is still fine, unless of course that class happened to be one that the JVM needs to run, like String. I'm assuming (though I could be wrong--but won't believe I am without appropriate support) that, just as my OS can prevent a malloc in my app from screwing up the OS other apps, so can the JVM prevent an OOME from screwing up the JVM itself.

    Sure the JVM may not be able to allocate enough memory to do its job, but when that happens, I expect it to dump core, rather than returning control to my app via an OOME.
    you seem to have some special view of the jvm where it operates at a different level from everything else. to clarify, when i refer to the jvm, i am including all of the classes which make up the jdk, as many of them are fairly "critical" to the overall functioning of the jvm (e.g. all the classes in java.lang, java.lang.ref, java.lang.reflect, java.util). if the classloader is borked, or classes are partially loaded, then your application isn't going to be able to do anything useful. i'm not aware of any "special" treatment of jdk classes which would force the jvm to dump core instead of throw an OOME if it can't proceed.
  • 10. Re: Why does Exception allows Throwable as a cause
    796440 Guru
    Currently Being Moderated
    jtahlborn wrote:
    you seem to have some special view of the jvm where it operates at a different level from everything else.
    I do. My app runs within the JVM, and since the JVM manages my app's heap, I expect control to come back to my app when that heap has been exhausted, but not when the JVM has become internally corrupt.
    to clarify, when i refer to the jvm, i am including all of the classes which make up the jdk, as many of them are fairly "critical" to the overall functioning of the jvm (e.g. all the classes in java.lang, java.lang.ref, java.lang.reflect, java.util). if the classloader is borked, or classes are partially loaded, then your application isn't going to be able to do anything useful. i'm not aware of any "special" treatment of jdk classes which would force the jvm to dump core instead of throw an OOME if it can't proceed.
    I really don't understand what point you're trying to make here. Partially loaded classes? Borked Classloader? Eh?

    If you're saying that when I call new java.util.X(), and that ends up 5 layers deeper calling new java.lang.Y(), that you're considering X's call to new Y() as part of the JVM, I certainly don't consider that the case. If those calls fail, then the JVM--the executable that is managing my app--has no reason to be corrupt. An OOME will be generated and propagate up to my code, which will continue to propagate it until it's (presumably) caught by catch Throwable at an architectural boundary. My app may or may not be able to recover, but there's no reason to think the environment in which it's running is corrupt.

    If the 5-layer-deep call to new java.lang.Y() ends up with the JVM unable to malloc() for its own bookkeeping, even though there may be enough heap left for my objects, then I wouldn't expect OOME, or if I got it, only if the JVM was still in a coherent state.

    In short, since the JVM manages my app's memory, I should only get an OOME, with control returning to my app, if the problem is entirely within my app, but not within the JVM. Again, I may be mistaken here, but I think it's a reasonable assumption. I welcome any authoritative doc that refutes it though.
  • 11. Re: Why does Exception allows Throwable as a cause
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jtahlborn wrote:
    jverd wrote:
    Do you have a reference to support that? If so, then I amend my example above to, "An app throws any other Error +except+ OOME..." And if this is the case, then anywhere that catches Error should first catch OOME and rethrow it, since whatever recovery is done for Error in general is unlikely to succeed for OOME.
    what reference do you need? open up Class.java or ClassLoader.java. what is going to happen if an OOME gets thrown half way through loading some new classes or a new classloader? i would imagine the jdk implementors attempt to make that code somewhat safe, but i highly doubt is is 100% impervious to a random OOME. and if a class or classloader is in a bad state, i can't imagine that your application is going to continue happily along.
    Errr... I am rather certain that it will in fact.

    Especially for those classes because those classes are specifically required to deal with the possibility that exceptions, some rather serious ones, will prevent a class from loading.

    The problem with OOME is not that it leaves the VM in a bad state.

    The problem is that the conditions that lead to the OOME in the first place can result in the throw occurring anywhere in the entire application.
  • 12. Re: Why does Exception allows Throwable as a cause
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jverd wrote:
    If you're saying that when I call new java.util.X(), and that ends up 5 layers deeper calling new java.lang.Y(), that you're considering X's call to new Y() as part of the JVM, I certainly don't consider that the case. If those calls fail, then the JVM--the executable that is managing my app--has no reason to be corrupt. An OOME will be generated and propagate up to my code, which will continue to propagate it until it's (presumably) caught by catch Throwable at an architectural boundary. My app may or may not be able to recover, but there's no reason to think the environment in which it's running is corrupt.

    If the 5-layer-deep call to new java.lang.Y() ends up with the JVM unable to malloc() for its own bookkeeping, even though there may be enough heap left for my objects, then I wouldn't expect OOME, or if I got it, only if the JVM was still in a coherent state.

    In short, since the JVM manages my app's memory, I should only get an OOME, with control returning to my app, if the problem is entirely within my app, but not within the JVM. Again, I may be mistaken here, but I think it's a reasonable assumption. I welcome any authoritative doc that refutes it though.
    Not sure that is true although it might depend on what you mean.

    If you attempt to allocate a large number of threads I believe you get a OOME. Not because you are out of memory but rather because you are out of a native resource associated with threads which means no more can be created.

    Permgen errors also cause OOMEs too.

    Both of those would seem internal to the VM but the OOME results.
  • 13. Re: Why does Exception allows Throwable as a cause
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    jverd wrote:
    An app server is managing several applications. One of them throws OutOfMemoryError. The app server catches it and shuts the offending app down as gracefully as possible, without disturbing the other apps.
    A better example - AbstractMethodError in a plugin system.

    Definitely an error and definitely recoverable (probably) for a standard plugin system. And not something that you want the server to exit because.
  • 14. Re: Why does Exception allows Throwable as a cause
    796440 Guru
    Currently Being Moderated
    jschell wrote:
    jverd wrote:
    If you're saying that when I call new java.util.X(), and that ends up 5 layers deeper calling new java.lang.Y(), that you're considering X's call to new Y() as part of the JVM, I certainly don't consider that the case. If those calls fail, then the JVM--the executable that is managing my app--has no reason to be corrupt. An OOME will be generated and propagate up to my code, which will continue to propagate it until it's (presumably) caught by catch Throwable at an architectural boundary. My app may or may not be able to recover, but there's no reason to think the environment in which it's running is corrupt.

    If the 5-layer-deep call to new java.lang.Y() ends up with the JVM unable to malloc() for its own bookkeeping, even though there may be enough heap left for my objects, then I wouldn't expect OOME, or if I got it, only if the JVM was still in a coherent state.

    In short, since the JVM manages my app's memory, I should only get an OOME, with control returning to my app, if the problem is entirely within my app, but not within the JVM. Again, I may be mistaken here, but I think it's a reasonable assumption. I welcome any authoritative doc that refutes it though.
    Not sure that is true although it might depend on what you mean.

    If you attempt to allocate a large number of threads I believe you get a OOME. Not because you are out of memory but rather because you are out of a native resource associated with threads which means no more can be created.

    Permgen errors also cause OOMEs too.

    Both of those would seem internal to the VM but the OOME results.
    Fair enough. I wouldn't expect any of those cases to leave the VM in a corrupt state though.
1 2 3 Previous Next

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points