转载请附上本文地址:

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

本文参考:

JAVA源码

http://swiftlet.net/archives/998

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).

转载请附上本文地址:

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

本文参考:

JAVA源码

http://swiftlet.net/archives/998

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

JAVA基础 Exception, Error的更多相关文章

  1. Java 基础 - Exception和Error

    综述 Exception 和 Error 都是继承了 Throwable 类,在 Java 中只有 Throwable 类型的实例才可以被抛出(throw)或者捕获(catch),它是异常处理机制的基 ...

  2. Java基础-异常(Exception)处理

    Java基础-异常(Exception)处理 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.异常的概述 什么是异常?Java代码在运行时期发生的问题就是异常.在Java中,把异 ...

  3. Java异常处理总结Exception\Error

    Java异常处理总结Exception\Error 2012-12-28 08:17:17|  分类: JAVA |  标签:java  |举报|字号 订阅   Java异常处理总结          ...

  4. 2015年11月26日 Java基础系列(五)异常Exception

    序,异常都是标准类Throwable的一些子类的对象. Throwable类的几个方法 1 getMessage() 返回描述该异常的信息 2 printStackTrace() 把消息和栈的跟踪记录 ...

  5. nested exception is java.lang.RuntimeException: Error parsing Mapper XML. Cause: java.lang.IllegalArgumentException: Result Maps collection already contains value for

    org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'daoSupport': ...

  6. Error initializing endpoint java.lang.Exception: Socket bind failed: [730048] ?????????×???(Э?é/???????/???)????í??

    2010-5-18 22:00:38 org.apache.catalina.core.AprLifecycleListener lifecycleEvent 信息: The Apache Tomca ...

  7. Kafka中错误:Unrecognized VM option ‘UseCompressedOops’ Error: Clould not create the Java Vritual Machine. Error: A fatal exception has occurres . Program will exit.

    错误的描述: 在kafka安装目录下,执行 $ bin/zookeeper-server-start.sh config/zookeeper.properties & Unrecognized ...

  8. Java的Exception和Error面试题10问10答

    在Java核心知识的面试中,你总能碰到关于 处理Exception和Error的面试题.Exception处理是Java应用开发中一个非常重要的方面,也是编写强健而稳定的Java程序的关键,这自然使它 ...

  9. java virtual machine launcher Error:Could not create the Java Virtual Machine. Error:A Fatal exception has occurred,Program will exit.

    Error:Could not create the Java Virtual Machine. Error:A Fatal exception has occurred,Program will e ...

随机推荐

  1. 关于 feature team 的一些内容

    矩阵式管理,是常见的经典管理架构.其最早起源于美国的航空航天部门,然后被美国人带到了日本,然后被日本人带到了台湾,然后台湾人带到大陆...矩阵管理最典型的特征是,组织架构按职能与专业划分,项目由跨越部 ...

  2. Ubuntu下deb文件及tgz文件安装

    dpkg 是Debian Package的简写,是为Debian 专门开发的套件管理系统,方便软件的安装.更新及移除.所有源自Debian的Linux发行版都使用dpkg,例如Ubuntu.Knopp ...

  3. Day11-协程/异步IO/RabbitMQ

    协程,又称微线程,纤程.英文名Coroutine.一句话说明什么是线程:协程是一种用户态的轻量级线程. 协程拥有自己的寄存器上下文和栈.协程调度切换时,将寄存器上下文和栈保存到其他地方,在切回来的时候 ...

  4. oracle--游标--bai

    --复制表 create table emp as(select * from scott.emp); select * from emp; --(1) 最简单的游标 declare --声明并初始化 ...

  5. MVC分页

    http://www.cnblogs.com/iamlilinfeng/p/4075292.html 目录 一.Contrl与View数据传递(多表数据) 二.分页控件介绍 三.MVC源码说明 四.源 ...

  6. linux命令汇总

    GPU使用率 使用率查看,GPU-Util $ nvidia-smi 实时查看 $ watch [options] command 最常用的参数是 -n, 后面指定是每多少秒来执行一次命令. 监视显存 ...

  7. Nginx 颁发自签证书

    首先,确保安装了OpenSSL库,并且安装Nginx时使用了–with-http_ssl_module参数. 1:进入生成证书的目录 cd /usr/local/nginx/conf 2:使用open ...

  8. Struts2--属性设置方式

    Struts2自动获取/设置数据的方式一共分为两种 属性驱动(FieldDriven) 模型驱动(ModelDriven) 属性驱动 属性又分为两种: |- 基本数据类型 |- JavaBean属性类 ...

  9. remove name="ProxyModule“会导致重复执行

    <?xml version="1.0" encoding="utf-8"?> <!-- 有关如何配置 ASP.NET 应用程序的详细信息,请访 ...

  10. thinkphp一句话疑难解决笔记 3

    错误调试, E($msg)? 这个是tp内置的E 方法, E 函数. 它是tp抛异常 的另外一种方式. 默认的异常处理方式是, 在 框架下的 ThinkPHP/Tpl/think_exception. ...