Exception - Summary

Exception - Summary

• Exceptions identify errors that arise in your program.

• Exceptions are objects of subclasses of the Throwable class.

• Java includes a set of standard exceptions that may be thrown automatically, as a result of errors in your code, or may be thrown by methods in the standard classes in Java.

• If a method throws exceptions that aren’t caught, and aren’t represented by subclasses of the Error class or by subclasses of the RuntimeException class, then you must identify the exception classes in a throws clause in the method definition.

• If you want to handle an exception in a method, you must place the code that may generate the exception in a try block. A method may have several try blocks.

• Exception handling code is placed in a catch block that immediately follows the try block that contains the code that can throw the exception. A try block can have multiple catch blocks that each deals with a different type of exception.

• A finally block is used to contain code that must be executed after the execution of a try block, regardless of how the try block execution ends. A finally block will always be executed before execution of the method ends.

• You can throw an exception by using a throw statement. You can throw an exception anywhere in a method. You can also rethrow an existing exception in a catch block to pass it to the calling method.

• You can define your own exception classes that, in general, should be derived from the class Exception.

• Exceptions come in two flavors: checked and unchecked.

• Checked exceptions include all subtypes of Exception, excluding classes that extend RuntimeException.

• Checked exceptions are subject to the handle or declare rule; any method that might throw a checked exception (including methods that invoke methods that can throw a checked exception) must either declare the exception using the throws keyword, or handle the exception with an appropriate try/catch.

• Subtypes of Error or RuntimeException are unchecked, so the compiler doesn’t enforce the handle or declare rule. You’re free to handle them, and you’re free to declare them, but the compiler doesn’t care one way or the other.

• If you use an optional finally block, it will always be invoked, regardless of whether an exception in the corresponding try is thrown or not, and regardless of whether a thrown exception is caught or not.

• The only exception to the finally-will-always-be-called rule is that a finally will not be invoked if the JVM shuts down. That could happen if code from the try or catch blocks calls  System.exit(), in which case the JVM will not start your finally block.

• Just because finally is invoked does not mean it will complete. Code in the finally block could itself raise an exception or issue a System.exit().

• Uncaught exceptions propagate back through the call stack, starting from the method where the exception is thrown and ending with either the first method that has a corresponding catch for that exception type or a JVM  shutdown (which happens if the exception gets to main(), and main() is “ducking” the exception by declaring it).

• You can create your own exceptions, normally by extending Exception or one of its subtypes. Your exception will then be considered a checked exception, and the compiler will enforce the handle or declare rule for that exception.

• All catch blocks must be ordered from most specific to most general. For example, if you have a catch clause for both IOException and Exception, you must put the catch for IOException first (in order, top to bottom in your code). Otherwise, the IOException would be caught by catch(Exception e), because a catch argument can catch the specified exception or any of its subtypes! The compiler will stop you from defining catch clauses that can never be reached (because it sees that the more specific exception will be caught first by the more general catch).

• Exceptions are caught by the closest exception handler (for the try block from which the exception was thrown) specifying an appropriate type.

• An exception terminates the block in which the exception occurred.
• A handler may rethrow the object to an outer try block.

• catch( Exception exception ) catches all Exceptions

• catch( Throwable throwable ) catches all Exceptions and Errors

• If no handler matches a particular thrown object, the search for a match continues in an enclosing try block

• It is possible that the handler that catches an exception may decide it cannot process the exception. In this case, the handler can simply rethrow the exception. A throw followed by the exception object name rethrows the exception.

• Even if a handler can process an exception, and regardless of whether it does any processing on that exception, the handler can rethrow the exception for further processing outside the handler. A rethrown exception is detected by the next enclosing try block (normally in a calling method) and is handled by an appropriate exception handler (if there is one) listed after that enclosing try block.

• A throws clause lists the checked exceptions that may be thrown from a method. A method may throw the indicated exceptions, or it may throw subclass types. If a checked exception not listed in the throws clause is thrown, a syntax error occurs.

• A powerful reason for using inheritance with exceptions is to catch a variety of related errors easily with concise notation. One could certainly catch each type of subclass exception object individually, but it is more concise to simply catch the superclass exception object.