public class Throwable extends Object implements Serializable
类别
java.lang.Object下的java.lang.Throwable
所有已经实现的接口
Serializable
直接已知的子类
Error,Exception
对该类的理论描述
The 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 throw statement. Similarly, only this class or one of its subclasses can be the argument type in a catch clause. For the purposes of compile-time checking of exceptions, Throwable and any subclass of Throwable that is not also a subclass of either RuntimeException or Error are regarded as checked exceptions.
Throwable类是JAVA语言中所有errors和exceptions的超类.只有对象是Throwable类(或其子类Error/Exceptions)的实例instance时,才能被JVM或者Java throw语句抛出.类似的,只有此类或其子孙类才可以成为catch从句中的参数类型。编译时检查的异常,Throwable和其子类中不属于RuntimeException或Error子类的异常,都被认为是经过检查的异常。
Instances of two subclasses, Error and 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).
Throwable类的两个子类Error和Exception的对象instance,在惯常中被用于表示意外的发生。通常,这些类的实例是在特殊情况的背景下新建的,以便包括相关信息(如堆栈跟踪数据)
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 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.
Throwable包含其线程在创建时的执行栈的快照。它还可以包含一个消息字符串,给出关于错误的更多信息。随着时间的推移,一个 throwable 可以抑制其他 throwable 的传播。最后,throwable还可以包含一个原因:导致这个throwable被构造的另一个throwable。这种因果信息的记录被称为链式异常设施,因为原因本身可以有一个原因,以此类推,导致一个异常的 "链",每个都是由另一个引起的。
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).
一个可抛物可能有原因的原因是,抛出它的类是建立在一个较低层的抽象之上的,上层的操作由于下层的失败而失败。让下层抛出的可抛物向外传播是不好的设计,因为它通常与上层所提供的抽象无关。此外,假设下层的异常是一个被检查的异常(Error或者RuntimeException),这样做会把上层的API与它的实现细节联系起来。抛出一个 "包装好的异常"(即包含一个原因的异常)允许上层将故障的细节传达给它的调用者,而不会产生上述任何一个缺点。它保留了改变上层实现的灵活性,而不改变它的API(特别是它的方法所抛出的异常集合)。
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 java.io. Suppose the internals of the add method can throw an IOException. The implementation can communicate the details of the IOException to its caller while conforming to the Collection interface by wrapping the IOException in an appropriate unchecked exception. (The specification for the persistent collection should indicate that it is capable of throwing such exceptions.)
一个可抛物可能有原因的第二个原因是,抛出它的方法必须符合一个通用的接口,这个接口不允许该方法直接抛出原因。例如,假设一个持久化集合符合Collection接口,并且它的持久化是在java.io上实现的。假设添加方法的内部可以抛出一个IOException。该实现可以将IOException的细节传达给它的调用者,同时通过将IOException包装在一个适当的未检查的异常中来符合集合接口。(持久化集合的规范应该指出它能够抛出这样的异常)。
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 Throwable constructors that takes a cause. Because the 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 Throwable.
一个原因可以通过两种方式与一个可抛物相关联:通过一个将原因作为参数的构造函数,或者通过 initCause(Throwable) 方法。希望允许将原因与之关联的新可抛类应该提供接受原因的构造函数,并委托(也许是间接地)接受原因的可抛类构造函数之一。因为 initCause 方法是公开的,所以它允许原因与任何可抛类相关联,甚至是 "传统可抛类",其实现早于 Throwable 中的异常链机制。
By convention, class Throwable and its subclasses have two constructors, one that takes no arguments and one that takes a 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 Throwable (the cause), and one that takes a String (the detail message) and a Throwable (the cause).