Exception

Throwable:
toString():

Exception_第1张图片

Exception_第2张图片

 printStackTrace()

Exception_第3张图片

捕获后重新抛出:

printStackTrace()方法显示的将是原来异常抛出点的调用栈信息,而并非重新抛出点的信息。想要更新这个信息,可以调用fillInStackTrace()方法,这将返回一个Throwable对象,它是通过把当前调用栈信息填入原来那个异常对象而建立的。

如果抛出一个新异常,有关原来异常发生点的信息会丢失,剩下的是与新的抛出点有关的信息

异常链:

在Throwable子类中,只有三种基本的异常类提供了带cause参数的构造器,它们是Error,Exception以及RuntimeException。如果要想把其他类型的异常连接起来,应该使用initCause()方法而不是构造器

缺憾:异常丢失

1.try中抛出的异常被finally中抛出的异常覆盖掉

2.从finally return会使得finally之前的异常丢失 

异常限制:

当覆盖方法的时候,只能抛出在基类方法的异常说明里列出的那些异常。但这个限制对构造器不起作用,只要包含基类构造器的异常说明,可以抛出任意其他异常.同时派生类的构造器不能捕获基类构造器抛出的异常

但是

派生类方法可以不抛出异常,想象一个方法在一个抽象类和接口中都有定义且声明了没有继承关系的2中异常,那么在子类中好像声明抛出任何异常都是不正确的。

这也导致了一个出现在基类方法的异常说明的异常,不一定会出现在派生类方法的异常说明里,这点同继承的规则明显不同,在继承中,基类的方法必须出现在派生类里,换句话说,在继承继承和覆盖的过程中,某个特定方法的“异常说明的接口”不是变大而是变小了--这恰好和类接口在继承时的情形相反。

构造器:

对于在构造可能会抛出异常,并且要求清理的类,最安全的使用方式是使用嵌套的try子句

 

你可能感兴趣的:(Exception)