黑马程序员技术交流社区

标题: 自定义异常继承Exception的原因，为什么不继承Throwable [打印本页]

作者: 吕振中 时间: 2013-9-5 13:03
标题: 自定义异常继承Exception的原因，为什么不继承Throwable
本帖最后由吕振中于 2013-9-6 15:03 编辑

以下这个总结是毕老师基础视频第9天第10节末尾所提到的，看了好几遍实在是理解不了了，求大神们帮解释一下。{:soso_e181:}

自定义异常继承Exception原因：
异常体系有一个特点：因为异常类和异常对象都被抛出。
他们都具备可抛性。这个可抛性是Throwable这个体系中独有特点。

作者: 辛春鹏 时间: 2013-9-5 14:45
我是这样理解的，也不知道对不对啊。Throwable有两个子类Exception和Error。Error 是 Throwable 的子类，用于指示合理的应用程序不应该试图捕获的严重问题。Exception 类及其子类是的一种形式，它指出了合理的应用程序想要捕获的条件。我们自定义异常，就是为了解决问题，扑捉异常的，所以直接继Exception就好了。

作者: 陶智第 时间: 2013-9-5 15:22
Throwable是可抛的意思。在Throwable体系中Error类及其子类也具有可抛性。但在这里是需要定义一个自定义异常类。所以继承Exception就合情合理了。

作者: 苏联兵 时间: 2013-9-5 20:56
本帖最后由苏联兵于 2013-9-5 20:58 编辑

首先在Throwable类中具有Error和Exception类这两个直接子类，而Error类主要作用是用于表示硬件相关的错误，所以继承Error类或者是Throwable是没有任何意义的，从而让自定义类直接继承Exception类。Throwable是所有异常的父类抛出它的类构建在低层抽象之中，而高层操作由于低层操作的失败而失败。让低层抛出的 throwable 向外传播是一种糟糕的设计方法，因为它通常与高层提供的抽象不相关。此外，这样做将高层 API 与其实现细节关联起来，假定低层异常是经过检查的异常。抛出“经过包装的异常”（即包含 cause 的异常）允许高层与其调用方交流失败详细信息，而不会招致上述任何一个缺点。这种方式保留了改变高层实现而不改变其 API 的灵活性（尤其是，异常集合通过其方法抛出）。导致 throwable cause 的另一个 cause 是，抛出它的方法必须符合通用接口，而通用接口不允许方法直接抛出 cause。例如，假定持久集合符合 Collection 接口，而其持久性在 java.io 的基础上实现。假定 add 方法的内部可以抛出 IOException。实现可以与其调用方交流 IOException 的详细消息，同时通过以一种合适的未检查的异常来包装 IOException，使其符合 Collection 接口。（持久集合的规范应该指示它能够抛出这种异常。）
Throwable是属于一个高级别的处理异常的类，而且只有当对象是此类（或其子类之一）的实例时，才能通过 Java 虚拟机或者 Java throw 语句抛出。类似地，只有此类或其子类之一才可以是 catch 子句中的参数类型。
你用一个高级别的异常类去处理低级别的异常很明显不合适，还有你直接继承Throwable在去实例化子类对象，在通过子类对象去处理异常，按照这样的思路为了处理一个异常我们大动干戈的整那么多代码，如果为了体验写代码的乐趣的话可以试试，真正开发还是回归正道吧，这样做不仅让程序很臃肿而且还完全没有体现出Java异常处理的特点。希望能帮到你。不对的地方还请指正。

作者: 黄文伯 时间: 2013-9-6 10:31
亲，如问题已解决请将分类的“未解决”改为“已解决”。
以后的问题贴也要及时更改分类哦~

作者: 吕振中 时间: 2013-9-6 14:43

苏联兵发表于 2013-9-5 20:56
首先在Throwable类中具有Error和Exception类这两个直接子类，而Error类主要作用是用于表示硬件相关的错误， ...

问题已经解决，好像突然之间又明白了很多问题，{:soso_e179:}

作者: 苏联兵 时间: 2013-9-6 15:38

吕振中发表于 2013-9-6 14:43
问题已经解决，好像突然之间又明白了很多问题，

能把问题想明白对于解决问题是很有帮助的，加油！！！

欢迎光临黑马程序员技术交流社区 (http://bbs.itheima.com/)

黑马程序员IT技术论坛 X3.2