is handling instance of Error or its subclass is also called "exception handling" ??

[Monalisa Das]

I have studied about the hierarchy of exception classes in which Throwable class comes at the top and two of its direct subclasses are Error and Exception..I just want to ask if in some code snippet we throw an instance of Error or its subclass within the try catch block then will that be also called "exception handling" ? I am asking this because Error class is not a child class of Exception therefore cant be said an Exception, therefore handling the same should not be called exception handling

[Jelle Klap]

I would say yes, because exception in "exception handling" is not directly related to the class Exception, but more generally to exceptional behavior during the flow of a program. When that results in a situation you can deal with you enter the realm of the checked exceptions, of which Exception is the root class. When this results in an unexpected situation that you don't typically know how to handle sensibly, you enter the realm of the unchecked exceptions, of which RuntimeException is the root class. Both of these situations usually leave an application in a state it can recover from, though. If the situation is so dire that the application can't reasonably recover from it then the JVM throws a subtype of Error. For instance, when the JVM runs out of memory it throws an OutOfMemoryError. You could argue, then, that an Error is not subject to exception handling, because you can't reasonably handle it, but the fact is that you are allowed to do so. It's perfectly legal to catch Error, or even Throwable, using the exception handling mechanism that try-catch-finally offers. You shouldn't (typically), but you can.

[Monalisa Das]

Jelle Klap wrote:I would say yes, because exception in "exception handling" is not directly related to the class Exception, but more generally to exceptional behavior during the flow of a program. When that results in a situation you can deal with you enter the realm of the checked exceptions, of which Exception is the root class. When this results in an unexpected situation you don't typically know how to handle sensibly, you enter the realm of the unchecked exceptions, of which RuntimeException is the root class. Both of these situations usually leave an application in a state it can recover from, though. If the situation is so dire that the application can't reasonably recover from it the JVM throws a subtype of Error. For instance, when the JVM runs out of memory it throws an OutOfMemoryError. You could argue, then, that an Error is not subject to exception handling, because you can't reasonably handle it, but the fact is that you are allowed to do so. It's perectly legal to catch Error, or even Throwable, using the exception handling mechanism that try-catch-finally offers. You shouldn't (typically), but you can.

thanks for your answer, i got your point but i dint understood when you said that "when situation can be dealt that category falls into checked and when cant be dealt then checked".. please elaborate quoting some sample exceptions.

[Tony Docherty]

Unchecked exceptions normally relate to programming defects such as accessing array elements that are beyond the size of the array, dereferencing null etc, whereas checked exceptions generally relate to conditions outside the progams control such as invalid user input, database problems etc.

Any method that throws a Checked exception must specify which exceptions (or classes of exception) it throws in the method signature whereas unchecked exceptions do not need to be declared. This is because in most cases if the programmer knew an unchecked exception was going to be thrown by a method he/she would take steps to ensure it wasn't being generated in the first place.

[Jelle Klap]

Monalisa Das wrote:
thanks for your answer, i got your point but i dint understood when you said that "when situation can be dealt that category falls into checked and when cant be dealt then checked".. please elaborate quoting some sample exceptions.

Checked and unchecked exceptions differ in that checked exceptions are subject to the catch or specify requirement, whereas unchecked exceptions are not. Checked exceptions are all subtypes of Exception, excluding the subtypes of RuntimeException. Those are the unchecked exceptions. Checked exceptions either need to be handled with a try-catch construct or the method / constructor needs to explicitly specify that it doesn't handle the exception type by adding it to a throws clause. That way the code that calls it knows to expect exceptions of that type. There is no such requirement for unchecked exceptions. An unchecked exception may be thrown without the need to specify its type in a throws clause. The consequence of this is that client code can't reasonably expect unchecked exceptions to occur, and when they do occur the client code doesn't usually have a try-catch in place to handle them. Uncheck exceptions, then, are only suitable for those situations where you don't expect the calling code to be able to handle the exceptional situation. Bugs in a program are the most frequent cause of unchecked exceptions occurring of which NullPointerException is a prime example.

Edit: too late again.