The {@code Throwable} class is the superclass of all errors and
exceptions in the Java language. Only objects that are instances of this
class (or one of its subclasses) are thrown by the Java Virtual Machine or
can be thrown by the Java {@code throw} statement. Similarly, only
this class or one of its subclasses can be the argument type in a
{@code catch} clause.
For the purposes of compile-time checking of exceptions, {@code
Throwable} and any subclass of {@code Throwable} that is not also a
subclass of either RuntimeException or Error are
regarded as checked exceptions.

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).

Constructs a new throwable with the specified cause and a detail
message of {@code (cause==null ? null : cause.toString())} (which
typically contains the class and detail message of {@code cause}).
This constructor is useful for throwables that are little more than
wrappers for other throwables (for example, java.security.PrivilegedActionException ).

The #fillInStackTrace() method is called to initialize
the stack trace data in the newly created throwable.

Parameters:

cause - the cause (which is saved for later retrieval by the
#getCause() method). (A {@code null} value is
permitted, and indicates that the cause is nonexistent or
unknown.)

Constructs a new throwable with the specified detail message,
cause, {@linkplain #addSuppressed suppression} enabled or
disabled, and writable stack trace enabled or disabled. If
suppression is disabled, #getSuppressed for this object
will return a zero-length array and calls to #addSuppressed that would otherwise append an exception to the
suppressed list will have no effect. If the writable stack
trace is false, this constructor will not call #fillInStackTrace() , a {@code null} will be written to the
{@code stackTrace} field, and subsequent calls to {@code
fillInStackTrace} and #setStackTrace(StackTraceElement[]) will not set the stack
trace. If the writable stack trace is false, #getStackTrace will return a zero length array.

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.

Parameters:

message - the detail message.

cause - the cause. (A {@code null} value is permitted,
and indicates that the cause is nonexistent or unknown.)

enableSuppression - whether or not suppression is enabled or disabled

writableStackTrace - whether or not the stack trace should be
writable

Appends the specified exception to the exceptions that were
suppressed in order to deliver this exception. This method is
thread-safe and typically called (automatically and implicitly)
by the {@code try}-with-resources statement.

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.

Returns the cause of this throwable or {@code null} if the
cause is nonexistent or unknown. (The cause is the throwable that
caused this throwable to get thrown.)

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.

Creates a localized description of this throwable.
Subclasses may override this method in order to produce a
locale-specific message. For subclasses that do not override this
method, the default implementation returns the same result as
{@code getMessage()}.

Provides programmatic access to the stack trace information printed by
#printStackTrace() . Returns an array of stack trace elements,
each representing one stack frame. The zeroth element of the array
(assuming the array's length is non-zero) represents the top of the
stack, which is the last method invocation in the sequence. Typically,
this is the point at which this throwable was created and thrown.
The last element of the array (assuming the array's length is non-zero)
represents the bottom of the stack, which is the first method invocation
in the sequence.

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.

Returns an array containing all of the exceptions that were
suppressed, typically by the {@code try}-with-resources
statement, in order to deliver this exception.
If no exceptions were suppressed or {@linkplain
#Throwable(String, Throwable, boolean, boolean) suppression is
disabled}, an empty array is returned. This method is
thread-safe. Writes to the returned array do not affect future
calls to this method.

Initializes the cause of this throwable to the specified value.
(The cause is the throwable that caused this throwable to get thrown.)

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:

Prints this throwable and its backtrace to the
standard error stream. This method prints a stack trace for this
{@code Throwable} object on the error output stream that is
the value of the field {@code System.err}. The first line of
output contains the result of the #toString() method for
this object. Remaining lines represent data previously recorded by
the method #fillInStackTrace() . The format of this
information depends on the implementation, but the following
example may be regarded as typical:

java.lang.NullPointerException
at MyClass.mash(MyClass.java:9)
at MyClass.crunch(MyClass.java:6)
at MyClass.main(MyClass.java:3)

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:

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:

Sets the stack trace elements that will be returned by
#getStackTrace() and printed by #printStackTrace()
and related methods.
This method, which is designed for use by RPC frameworks and other
advanced systems, allows the client to override the default
stack trace that is either generated by #fillInStackTrace()
when a throwable is constructed or deserialized when a throwable is
read from a serialization stream.

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.