JAVA基础 Exception, Error

转载请附上本文地址：

http://www.cnblogs.com/nextbin/p/6219677.html

本文参考：

JAVA源码

http://blog.csdn.net/kingzone_2008/article/details/8535287

Exception和Error皆继承自Throwable。下面看看这3个类的源码注释，也就明白许多。

异常（Exception）分为checked异常和unchecked异常。除了RunTimeException及其子类外，所有的Exception都是checked异常。而checked异常需要被显式地捕抓或抛出，而unchecked异常则不需要。

Exception的源码注释为：

The class {@code Exception} and its subclasses are a form of {@code Throwable} that indicates conditions that a reasonable application might want to catch.

The class {@code Exception} and any subclasses that are not also subclasses of {@link RuntimeException} are checked exceptions. Checked exceptions need to be declared in a method or constructor's {@code throws} clause if they can be thrown by the execution of the method or constructor and propagate outside the method or constructor boundary.

错误（Error）一般不应该被捕抓。大多数的错误都是不正常的现象。尽管ThreadDeath错误是“正常”现象，它也是错误的子类，因为大多数应用都不应该捕抓。同unchecked异常一样，Error不需要被显式地捕抓或抛出。

Error的源码注释为：

An {@code Error} is a subclass of {@code Throwable} that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The {@code ThreadDeath} error, though a "normal" condition, is also a subclass of {@code Error} because most applications should not try to catch it.

A method is not required to declare in its {@code throws} clause any subclasses of {@code Error} that might be thrown during the execution of the method but not caught, since these errors are abnormal conditions that should never occur.

That is, {@code Error} and its subclasses are regarded as unchecked exceptions for the purposes of compile-time checking of exceptions.

Throwable包含调用栈和异常/错误信息。同时其可以携带一个原有（cause），即另一个Throwable，由此可形成链式Throwable，保留错误的源头。保留cause原因有二，其一，上层调用者需要知道下层被调用者的错误根源，其二，上层接口定义的抛出异常可能不允许直接抛出下层被调用者所抛出的异常

Throwable的源码注释为：

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 {@link RuntimeException} or {@link Error} are regarded as checked exceptions.

Instances of two subclasses, {@link java.lang.Error} and {@link 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 {@link java.util.Collection Collection} interface, and that its persistence is implemented atop {@code java.io}. Suppose the internals of the {@code add} method can throw an {@link java.io.IOException 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 {@link #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).