The Kinds and Causes of Exceptions

11.1 The Kinds and Causes of Exceptions

11.1.1 The Kinds of Exceptions

An exception is represented by an instance of the class Throwable (a direct subclass of Object ) or one of its subclasses.

Throwable and all its subclasses are, collectively, the exception classes.

Note that a subclass of Throwable must not be generic (§8.1.2).

The classes Exception and Error are direct subclasses of Throwable . Exception is the superclass of all the exceptions from which ordinary programs

may wish to recover. Error is the superclass of all the exceptions from which ordinary programs are not

ordinarily expected to recover. Error and all its subclasses are, collectively, the error classes.

The class Error is a separate subclass of Throwable , distinct from Exception in the class hierarchy, to allow programs to use the idiom " } catch (Exception e) { " (§11.2.3) to catch all exceptions from which recovery may be possible without catching errors from which recovery is typically not possible.

The class RuntimeException is a direct subclass of Exception . RuntimeException is the superclass of all the exceptions which may be thrown for many reasons during expression evaluation, but from which recovery may still

be possible.

EXCEPTIONS The Causes of Exceptions 11.1.2

RuntimeException and all its subclasses are, collectively, the runtime exception classes.

The unchecked exception classes are the runtime exception classes and the error classes.

The checked exception classes are all exception classes other than the unchecked exception classes. That is, the checked exception classes are all subclasses of Throwable other than RuntimeException and its subclasses and Error and its subclasses.

Programs can use the pre-existing exception classes of the Java SE platform API in throw statements, or define additional exception classes as subclasses of Throwable or of any of its subclasses, as appropriate. To take advantage of compile-time checking for exception handlers (§11.2), it is typical to define most new exception classes as checked exception classes, that is, as subclasses of Exception that are not subclasses of RuntimeException .

11.1.2 The Causes of Exceptions

An exception is thrown for one of three reasons: •A throw statement (§14.18) was executed. • An abnormal execution condition was synchronously detected by the Java virtual

machine, namely: ◆ evaluation of an expression violates the normal semantics of the Java

programming language (§15.6), such as an integer divide by zero. ◆ an error occurs while loading, linking, or initializing part of the program

(§12.2, §12.3, §12.4); in this case, an instance of a subclass of LinkageError is thrown.

◆ an internal error or resource limitation prevents the Java virtual machine from implementing the semantics of the Java programming language; in this case,

an instance of a subclass of VirtualMachineError is thrown. These exceptions are not thrown at an arbitrary point in the program, but rather at

a point where they are specified as a possible result of an expression evaluation or statement execution.

• An asynchronous exception occurred (§11.1.3).

11.1.3 Asynchronous Exceptions

Most exceptions occur synchronously as a result of an action by the thread in which they occur, and at a point in the program that is specified to possibly result in such

11.2 Compile-Time Checking of Exceptions EXCEPTIONS

an exception. An asynchronous exception is, by contrast, an exception that can potentially occur at any point in the execution of a program.

Asynchronous exceptions occur only as a result of: • An invocation of the (deprecated) stop method of class Thread or ThreadGroup .

The (deprecated) stop methods may be invoked by one thread to affect another thread or all the threads in a specified thread group. They are asynchronous because they may occur at any point in the execution of the other thread or threads.

• An internal error or resource limitation in the Java virtual machine that prevents it from implementing the semantics of the Java programming language. In this case, the asynchronous exception that is thrown is an instance of a subclass of VirtualMachineError .

Note that StackOverflowError , a subclass of VirtualMachineError , may be thrown synchronously by method invocation (§15.12.4.5) as well as asynchronously due to native method execution or Java virtual machine resource limitations. Similarly, OutOfMemoryError , another subclass of VirtualMachineError , may be thrown synchronously during object creation (§12.5), array creation (§15.10.1, §10.6), class initialization (§12.4.2), and boxing conversion (§5.1.7), as well as asynchronously.

The Java SE platform permits a small but bounded amount of execution to occur before an asynchronous exception is thrown.

Asynchronous exceptions are rare, but proper understanding of their semantics is necessary if high-quality machine code is to be generated.

The delay noted above is permitted to allow optimized code to detect and throw these exceptions at points where it is practical to handle them while obeying the semantics of the Java programming language. A simple implementation might poll for asynchronous exceptions at the point of each control transfer instruction. Since a program has a finite size, this provides a bound on the total delay in detecting an asynchronous exception. Since no asynchronous exception will occur between control transfers, the code generator has some flexibility to reorder computation between control transfers for greater performance. The paper Polling Efficiently on Stock Hardware by Marc Feeley, Proc. 1993 Conference on Functional Programming and Computer Architecture, Copenhagen, Denmark, pp. 179-187, is recommended as further reading.