jdk中关于java.lang.Throwable的描述是这样的:
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. Finally, it can contain a <i>cause</i>:another throwable that caused this throwable to get thrown. The cause facility is new in release 1.4. It is also known as the <i>chained exception</i> 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} interface, and that its persistence is implemented atop <tt>java.io</tt>. Suppose the internals of the <tt>put</tt> method can throw an {@link java.io.IOException IOException}. The implementation can communicate the details of the <tt>IOException</tt> to its caller while conforming to the <tt>Collection</tt> interface by wrapping the <tt>IOException</tt> in an appropriate unchecked exception. (The specification for the persistent collection should indicate that it is capable of throwing such exceptions.)
为什么Throwable的需要包含一个cause?原因有两个:
1)在一个多层的结构当中,底层的操作可能抛出了一些异常,假设这些异常都是checked exception, 为了不让这些底层的异常的信息丢失,必须catch住,或者在上层的方法中throws出来(异常传递),异常传递的做法很多时候是有害的,因为这样做相当于更改了自己的api, 上层的api受到底层的api的约束的做法是不明智的。 所以好的做法就是catch底层的exception, 然后将它转化为上层的exception,转化的方法就是通过Throwable的cause来转化。
2)如果有一个interface, 定义了一个方法doMethod(), 但是这个方法不扔出任何的exception; 有一个具体类implements了这个interface的doMethod(), 实现的过程中遇到了底层的checked exception, 所以必须catch, 但是由于doMethod()不扔出任何的异常, 所以只能够将checked exception封装在一个RuntimeException里边, 就像
public void doMethod()
{
try
{
...
}
catch(CheckedException ex)
{
throw new RuntimeException(ex);
}
}
这么做的结果是不会影响interface的api, 而且还保留了CheckedException的信息。
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. Finally, it can contain a <i>cause</i>:another throwable that caused this throwable to get thrown. The cause facility is new in release 1.4. It is also known as the <i>chained exception</i> 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} interface, and that its persistence is implemented atop <tt>java.io</tt>. Suppose the internals of the <tt>put</tt> method can throw an {@link java.io.IOException IOException}. The implementation can communicate the details of the <tt>IOException</tt> to its caller while conforming to the <tt>Collection</tt> interface by wrapping the <tt>IOException</tt> in an appropriate unchecked exception. (The specification for the persistent collection should indicate that it is capable of throwing such exceptions.)
为什么Throwable的需要包含一个cause?原因有两个:
1)在一个多层的结构当中,底层的操作可能抛出了一些异常,假设这些异常都是checked exception, 为了不让这些底层的异常的信息丢失,必须catch住,或者在上层的方法中throws出来(异常传递),异常传递的做法很多时候是有害的,因为这样做相当于更改了自己的api, 上层的api受到底层的api的约束的做法是不明智的。 所以好的做法就是catch底层的exception, 然后将它转化为上层的exception,转化的方法就是通过Throwable的cause来转化。
2)如果有一个interface, 定义了一个方法doMethod(), 但是这个方法不扔出任何的exception; 有一个具体类implements了这个interface的doMethod(), 实现的过程中遇到了底层的checked exception, 所以必须catch, 但是由于doMethod()不扔出任何的异常, 所以只能够将checked exception封装在一个RuntimeException里边, 就像
public void doMethod()
{
try
{
...
}
catch(CheckedException ex)
{
throw new RuntimeException(ex);
}
}
这么做的结果是不会影响interface的api, 而且还保留了CheckedException的信息。
本文详细解释了Java中Throwable类的cause机制,包括其应用场景和设计目的。主要探讨了两个场景:多层抽象结构中异常的传递和符合通用接口但需要处理底层异常的情况。
813

被折叠的 条评论
为什么被折叠?



