public class: Throwable [javadoc | source]
java.lang.Objectjava.lang.Throwable
All Implemented Interfaces:
Serializable
Instances of two subclasses, java.lang.Error and java.lang.Exception , are conventionally used to indicate that exceptional situations have occurred. Typically, these instances are freshly created in the context of the exceptional situation so as to include relevant information (such as stack trace data).
A throwable contains a snapshot of the execution stack of its thread at the time it was created. It can also contain a message string that gives more information about the error. Over time, a throwable can {@linkplain Throwable#addSuppressed suppress} other throwables from being propagated. Finally, the throwable can also contain a cause: another throwable that caused this throwable to be constructed. The recording of this causal information is referred to as the chained exception facility, as the cause can, itself, have a cause, and so on, leading to a "chain" of exceptions, each caused by another.
One reason that a throwable may have a cause is that the class that throws it is built atop a lower layered abstraction, and an operation on the upper layer fails due to a failure in the lower layer. It would be bad design to let the throwable thrown by the lower layer propagate outward, as it is generally unrelated to the abstraction provided by the upper layer. Further, doing so would tie the API of the upper layer to the details of its implementation, assuming the lower layer's exception was a checked exception. Throwing a "wrapped exception" (i.e., an exception containing a cause) allows the upper layer to communicate the details of the failure to its caller without incurring either of these shortcomings. It preserves the flexibility to change the implementation of the upper layer without changing its API (in particular, the set of exceptions thrown by its methods).
A second reason that a throwable may have a cause is that the method that throws it must conform to a general-purpose interface that does not permit the method to throw the cause directly. For example, suppose a persistent collection conforms to the Collection interface, and that its persistence is implemented atop {@code java.io}. Suppose the internals of the {@code add} method can throw an IOException . The implementation can communicate the details of the {@code IOException} to its caller while conforming to the {@code Collection} interface by wrapping the {@code IOException} in an appropriate unchecked exception. (The specification for the persistent collection should indicate that it is capable of throwing such exceptions.)
A cause can be associated with a throwable in two ways: via a constructor that takes the cause as an argument, or via the #initCause(Throwable) method. New throwable classes that wish to allow causes to be associated with them should provide constructors that take a cause and delegate (perhaps indirectly) to one of the {@code Throwable} constructors that takes a cause. Because the {@code initCause} method is public, it allows a cause to be associated with any throwable, even a "legacy throwable" whose implementation predates the addition of the exception chaining mechanism to {@code Throwable}.
By convention, class {@code Throwable} and its subclasses have two constructors, one that takes no arguments and one that takes a {@code String} argument that can be used to produce a detail message. Further, those subclasses that might likely have a cause associated with them should have two more constructors, one that takes a {@code Throwable} (the cause), and one that takes a {@code String} (the detail message) and a {@code Throwable} (the cause).
- author:
unascribed- - author:
Josh- Bloch (Added exception chaining and programmatic access to stack trace in 1.4.) - jls:
11.2- Compile-Time Checking of Exceptions - since:
JDK1.0-
| Constructor: |
|---|
The #fillInStackTrace() method is called to initialize the stack trace data in the newly created throwable. |
The #fillInStackTrace() method is called to initialize the stack trace data in the newly created throwable.
|
The #fillInStackTrace() method is called to initialize the stack trace data in the newly created throwable.
|
Note that the detail message associated with {@code cause} is not automatically incorporated in this throwable's detail message. The #fillInStackTrace() method is called to initialize the stack trace data in the newly created throwable.
|
Note that the other constructors of {@code Throwable} treat suppression as being enabled and the stack trace as being writable. Subclasses of {@code Throwable} should document any conditions under which suppression is disabled and document conditions under which the stack trace is not writable. Disabling of suppression should only occur in exceptional circumstances where special requirements exist, such as a virtual machine reusing exception objects under low-memory situations. Circumstances where a given exception object is repeatedly caught and rethrown, such as to implement control flow between two sub-systems, is another situation where immutable throwable objects would be appropriate.
|
| Method from java.lang.Throwable Summary: |
|---|
| addSuppressed, fillInStackTrace, getCause, getLocalizedMessage, getMessage, getStackTrace, getStackTraceDepth, getStackTraceElement, getSuppressed, initCause, printStackTrace, printStackTrace, printStackTrace, setStackTrace, toString |
| Methods from java.lang.Object: |
|---|
| clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Method from java.lang.Throwable Detail: |
|---|
The suppression behavior is enabled unless disabled {@linkplain #Throwable(String, Throwable, boolean, boolean) via a constructor}. When suppression is disabled, this method does nothing other than to validate its argument. Note that when one exception {@linkplain #initCause(Throwable) causes} another exception, the first exception is usually caught and then the second exception is thrown in response. In other words, there is a causal connection between the two exceptions. In contrast, there are situations where two independent exceptions can be thrown in sibling code blocks, in particular in the {@code try} block of a {@code try}-with-resources statement and the compiler-generated {@code finally} block which closes the resource. In these situations, only one of the thrown exceptions can be propagated. In the {@code try}-with-resources statement, when there are two such exceptions, the exception originating from the {@code try} block is propagated and the exception from the {@code finally} block is added to the list of exceptions suppressed by the exception from the {@code try} block. As an exception unwinds the stack, it can accumulate multiple suppressed exceptions. An exception may have suppressed exceptions while also being caused by another exception. Whether or not an exception has a cause is semantically known at the time of its creation, unlike whether or not an exception will suppress other exceptions which is typically only determined after an exception is thrown. Note that programmer written code is also able to take advantage of calling this method in situations where there are multiple sibling exceptions and only one can be propagated. |
If the stack trace of this {@code Throwable} {@linkplain Throwable#Throwable(String, Throwable, boolean, boolean) is not writable}, calling this method has no effect. |
This implementation returns the cause that was supplied via one of the constructors requiring a {@code Throwable}, or that was set after creation with the #initCause(Throwable) method. While it is typically unnecessary to override this method, a subclass can override it to return a cause set by some other means. This is appropriate for a "legacy chained throwable" that predates the addition of chained exceptions to {@code Throwable}. Note that it is not necessary to override any of the {@code PrintStackTrace} methods, all of which invoke the {@code getCause} method to determine the cause of a throwable. |
|
|
Some virtual machines may, under some circumstances, omit one or more stack frames from the stack trace. In the extreme case, a virtual machine that has no stack trace information concerning this throwable is permitted to return a zero-length array from this method. Generally speaking, the array returned by this method will contain one element for every frame that would be printed by {@code printStackTrace}. Writes to the returned array do not affect future calls to this method. |
|
|
|
This method can be called at most once. It is generally called from within the constructor, or immediately after creating the throwable. If this throwable was created with #Throwable(Throwable) or #Throwable(String,Throwable) , this method cannot be called even once. An example of using this method on a legacy throwable type without other support for setting the cause is:
try {
lowLevelOp();
} catch (LowLevelException le) {
throw (HighLevelException)
new HighLevelException().initCause(le); // Legacy constructor
}
|
class MyClass {
public static void main(String[] args) {
crunch(null);
}
static void crunch(int[] a) {
mash(a);
}
static void mash(int[] b) {
System.out.println(b[0]);
}
}
The backtrace for a throwable with an initialized, non-null cause
should generally include the backtrace for the cause. The format
of this information depends on the implementation, but the following
example may be regarded as typical:
HighLevelException: MidLevelException: LowLevelException
at Junk.a(Junk.java:13)
at Junk.main(Junk.java:4)
Caused by: MidLevelException: LowLevelException
at Junk.c(Junk.java:23)
at Junk.b(Junk.java:17)
at Junk.a(Junk.java:11)
... 1 more
Caused by: LowLevelException
at Junk.e(Junk.java:30)
at Junk.d(Junk.java:27)
at Junk.c(Junk.java:21)
... 3 more
Note the presence of lines containing the characters {@code "..."}.
These lines indicate that the remainder of the stack trace for this
exception matches the indicated number of frames from the bottom of the
stack trace of the exception that was caused by this exception (the
"enclosing" exception). This shorthand can greatly reduce the length
of the output in the common case where a wrapped exception is thrown
from same method as the "causative exception" is caught. The above
example was produced by running the program:
public class Junk {
public static void main(String args[]) {
try {
a();
} catch(HighLevelException e) {
e.printStackTrace();
}
}
static void a() throws HighLevelException {
try {
b();
} catch(MidLevelException e) {
throw new HighLevelException(e);
}
}
static void b() throws MidLevelException {
c();
}
static void c() throws MidLevelException {
try {
d();
} catch(LowLevelException e) {
throw new MidLevelException(e);
}
}
static void d() throws LowLevelException {
e();
}
static void e() throws LowLevelException {
throw new LowLevelException();
}
}
class HighLevelException extends Exception {
HighLevelException(Throwable cause) { super(cause); }
}
class MidLevelException extends Exception {
MidLevelException(Throwable cause) { super(cause); }
}
class LowLevelException extends Exception {
}
As of release 7, the platform supports the notion of
suppressed exceptions (in conjunction with the {@code
try}-with-resources statement). Any exceptions that were
suppressed in order to deliver an exception are printed out
beneath the stack trace. The format of this information
depends on the implementation, but the following example may be
regarded as typical:
Exception in thread "main" java.lang.Exception: Something happened
at Foo.bar(Foo.java:10)
at Foo.main(Foo.java:5)
Suppressed: Resource$CloseFailException: Resource ID = 0
at Resource.close(Resource.java:26)
at Foo.bar(Foo.java:9)
... 1 more
Note that the "... n more" notation is used on suppressed exceptions
just at it is used on causes. Unlike causes, suppressed exceptions are
indented beyond their "containing exceptions."
An exception can have both a cause and one or more suppressed exceptions:
Exception in thread "main" java.lang.Exception: Main block
at Foo3.main(Foo3.java:7)
Suppressed: Resource$CloseFailException: Resource ID = 2
at Resource.close(Resource.java:26)
at Foo3.main(Foo3.java:5)
Suppressed: Resource$CloseFailException: Resource ID = 1
at Resource.close(Resource.java:26)
at Foo3.main(Foo3.java:5)
Caused by: java.lang.Exception: I did it
at Foo3.main(Foo3.java:8)
Likewise, a suppressed exception can have a cause:
Exception in thread "main" java.lang.Exception: Main block
at Foo4.main(Foo4.java:6)
Suppressed: Resource2$CloseFailException: Resource ID = 1
at Resource2.close(Resource2.java:20)
at Foo4.main(Foo4.java:5)
Caused by: java.lang.Exception: Rats, you caught me
at Resource2$CloseFailException. |
|
|
If the stack trace of this {@code Throwable} {@linkplain Throwable#Throwable(String, Throwable, boolean, boolean) is not writable}, calling this method has no effect other than validating its argument. |
|
native int