The exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program’s instructions. Throwable is Java implementation of an idea of an exception.

When an error occurs within a method, the method creates an object and hands it off to the runtime system. The object, called an exception object, contains information about the error, including its type and the state of the program when the error occurred. Creating an exception object and handing it to the runtime system is called throwing an exception.

After a method throws an exception, the runtime system attempts to find something to handle it. The set of possible "somethings" to handle the exception is the ordered list of methods that had been called to get to the method where the error occurred. The list of methods is known as the call stack (see the next figure).

The runtime system searches the call stack for a method that contains a block of code that can handle the exception. This block of code is called an exception handler. The search begins with the method in which the error occurred and proceeds through the call stack in the reverse order in which the methods were called. When an appropriate handler is found, the runtime system passes the exception to the handler. An exception handler is considered appropriate if the type of the exception object thrown matches the type that can be handled by the handler.

The exception handler chosen is said to catch the exception. If the runtime system exhaustively searches all the methods on the call stack without finding an appropriate exception handler, as shown in the next figure, the runtime system (and, consequently, the program) terminates.

Below some of the most common types of Throwable in Java are listed. Their usage examples are provided in the eu.ciechanowiec.throwable.throwableproducer package.

Throwable and its subclasses (i.a. Error) can be thrown because during the compilation they are related with the athrow bytecode instruction (see Java Virtual Machine Specification at https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-2.html#jvms-2.10).

• throws

• try

• catch

• finally

• throw

1. The finally block always executes when the try block exits. This ensures that the finally block is executed even if an unexpected exception occurs (the unexpected exception is propagated to the caller).

2. An exception thrown from the finally block is propagated to the caller as an exception thrown from the outside of the try-catch block; in such a case any unexpected exception thrown from the try block and propagated from there to the caller is suppressed by the exception thrown from the finally block.

3. The finally block may not execute if the JVM exits while the try or catch code is being executed. For instance, if the System.exit(…​) command inside the try block is executed, the program immediately stops; even the finally block is not executed.

   • See eu.ciechanowiec.throwable.finally package.

1. With inline catch blocks (exception variable is final then):

   try {
      throw new IndexOutOfBoundsException("Sample exception");
   } catch (IndexOutOfBoundsException | ArithmeticException exception) {
      Logger.error(exception);
   }

2. With chained catch blocks:

   try {
      throw new IndexOutOfBoundsException("Sample exception");
   } catch (IndexOutOfBoundsException exception) {
      Logger.error(exception);
   } catch (RuntimeException exception) {
      Logger.error(exception);
   }

3. Exceptions must be caught from the narrower to the broader one. Two same types of exceptions cannot be multicaught.

4. In case of inline multicatch only one exception variable is possible.

5. Types in the inline multicatch block must be disjoint (i.e. that one of them cannot be the subclass of the another one), so that for IndexOutOfBoundsException and RuntimeException there will be different responses in catch blocks. For that reason the following code will not compile:

   try {
       throw new IndexOutOfBoundsException("Sample exception");
   } catch (IndexOutOfBoundsException | RuntimeException exception) {
       Logger.error(exception);
   }

6. Both Errors and Exceptions can be multicaught in the same block, both inline and chained.

7. See eu.ciechanowiec.throwable.multicatch package.

1. Any object that implements AutoCloseable or Closeable can be used as a resource. Neither null nor other objects can be passed as a resource - the code will not compile.

2. One or more resources can be declared in the try-with-resources block.

3. There is no practical difference between AutoCloseable and Closeable (only historical: AutoCloseable was introduced later and Closeable extends AutoCloseable).

4. To implement AutoCloseable or Closeable, the close() method must be implemented.

5. If any, even unexpected, exception occurs, close() methods of all specified resources are called, which closes those resources.

6. The resources are closed in the reverse order from which they were initialized.

7. Resources must be final, in that:

   • a local variable declared in a resource specification is implicitly declared final if it is not explicitly declared final,

   • an existing variable referred to in a resource specification must be a final or effectively final variable that is definitely assigned before the try-with-resources statement, or a compile-time error occurs.

8. It is possible to use bare try-with-resources block, without catch and finally block.

9. An exception from the closing of one resource does not prevent the closing of other resources. Such an exception is added as a suppressed to the exception that occurred it the try block, regardless of whether the exception from the try block was or wasn’t caught. If there were no exception thrown from the try block, the exception that occurred during the closing of one of resources will not be suppressed and will be propagated to the caller.

10. See eu.ciechanowiec.throwable.withresources package

• Checked exceptions thrown by critical methods force to handle them, which improves the program stability

• Checked exceptions describe some behaviour of the method

• It is possible to develop robust software without checked exceptions (e.g. C++ and C don’t have such a concept)

• Checked exceptions enforce the developer to handle them immediately, what can result in quickly and weakly provided exception handling

• Checked exceptions violate the open/closed principle. If a checked exception is thrown from a method and the catch is three levels above, that exception must be declared in the signature of each method in the chain. It means that a change at a low level of the software can force signature changes on many higher levels

• Checked exceptions break encapsulation because all functions in the path of a throw must know about details of that low-level exception.