A Java program should not try to handle the standard error
classes. Most of these error classes represent non-recoverable errors
and as such, they cause the Java runtime system to print an error
message and terminate program execution.
- AbstractMethodError
-
This error is thrown in response to an attempt to
invoke an abstract method.
- ClassCircularityError
-
This error is thrown when a circular reference among
classes is detected during class initialization.
- ClassFormatError
-
This error is thrown when an error is detected in
the format of a file that contains a class definition.
- Error
-
The appropriate subclass of this error is thrown
when an unpredictable error, such as running out of memory, occurs.
Because of the unpredictable nature of these errors, methods that
can throw objects that are instances of Error
or one of its subclasses are not required to declare that fact in
their throws clauses.
- ExceptionInInitializerError
-
This error is
thrown when an unexpected exception is thrown in a static initializer.
This error is new in Java 1.1.
- IllegalAccessError
-
This error is thrown when a class attempts to access
a field or call a method it does not have access to. Usually this
error is caught by the compiler; this error can occur at run-time
if the definition of a class changes after the class that references
it was last compiled.
- IncompatibleClassChangeError
-
This error or one of its subclasses is thrown when
a class refers to another class in an incompatible way. This situation
occurs when the current definition of the referenced class is incompatible
with the definition of the class that was found when the referring
class was compiled. For example, say class A
refers to a method in class B. Then, after class
A is compiled, the method is removed from class
B. When class A is loaded,
the run-time system discovers that the method in class B
no longer exists and throws an error.
- InstantiationError
-
This error is thrown in response to an attempt to
instantiate an abstract class or an interface.
Usually this error is caught by the compiler; this error can occur
at run-time if the definition of a class is changed after the class
that references it was last compiled.
- InternalError
-
This error is thrown to signal an internal error
within the virtual machine.
- LinkageError
-
The appropriate subclass of this error is thrown
when there is a problem resolving a reference to a class. Reasons
for this may include a difficulty in finding the definition of the
class or an incompatibility between the current definition and the
expected definition of the class.
- NoClassDefFoundError
-
This error is thrown when the definition of a class
cannot be found.
- NoSuchFieldError
-
This error is thrown in response to an attempt to
reference an instance or class variable that is not defined in the
current definition of a class. Usually this error is caught by the
compiler; this error can occur at run-time if the definition of a
class is changed after the class that references it was last compiled.
- NoSuchMethodError
-
This error is thrown in response to an attempt to
reference a method that is not defined in the current definition
of a class. Usually this error is caught by the compiler; this error
can occur at run-time if the definition of a class is changed after
the class that references it was last compiled.
- OutOfMemoryError
-
This error is thrown when an attempt to allocate
memory fails.
- StackOverflowError
-
This error is thrown when a stack overflow error
occurs within the virtual machine.
- ThreadDeath
-
This error is thrown by the stop()
method of a Thread object to kill the thread.
Catching ThreadDeath objects is not recommended.
If it is necessary to catch a ThreadDeath object,
it is important to re-throw the object so that it is possible to
cleanly stop the catching thread.
- UnknownError
-
This error is thrown when an error of unknown origins
is detected in the run-time system.
- UnsatisfiedLinkError
-
This error is thrown when the implementation of
a native method cannot be found.
- VerifyError
-
This error is thrown when the byte-code verifier
detects that a class file, though well-formed, contains some sort
of internal inconsistency or security problem.
- VirtualMachineError
-
The appropriate subclass of this error is thrown
to indicate that the Java virtual machine has encountered an error.