目录
程序运行时,发生的不被期望的事件,它阻止了程序按照程序员的预期正常执行,这就是异常。异常发生时,是任程序自生自灭,立刻退出终止,还是输出错误给用户?或者用C语言风格:用函数返回值作为执行状态?
Java提供了更加优秀的解决办法:异常处理机制。
异常处理机制能让程序在异常发生时,按照代码的预先设定的异常处理逻辑,针对性地处理异常,让程序尽最大可能恢复正常并继续执行,且保持代码的清晰。
Java中的异常可以是函数中的语句执行时引发的,也可以是程序员通过throw 语句手动抛出的,只要在Java程序中产生了异常,就会用一个对应类型的异常对象来封装异常,JRE就会试图寻找异常处理程序来处理异常。
Throwable类是Java异常类型的顶层父类,一个对象只有是 Throwable 类的(直接或者间接)实例,他才是一个异常对象,才能被异常处理机制识别。JDK中内建了一些常用的异常类【如图】,我们也可以自定义异常。
错误:Error类以及他的子类的实例,代表了JVM本身的错误。错误不能被程序员通过代码处理,Error很少出现。因此,程序员应该关注Exception为父类的分支下的各种异常类。
异常:Exception以及他的子类,代表程序运行时发送的各种不期望发生的事件。可以被Java异常处理机制使用,是异常处理的核心。
总体上我们根据Javac对异常的处理要求,将异常类分为2类。
非检查异常(unckecked exception):Error 和 RuntimeException 以及他们的子类。javac在编译时,不会提示和发现这样的异常,不要求在程序处理这些异常。所以如果愿意,我们可以编写代码处理(使用try...catch...finally)这样的异常,也可以不处理。对于这些异常,我们应该修正代码,而不是去通过异常处理器处理 。这样的异常发生的原因多半是代码写的有问题。如除0错误ArithmeticException,错误的强制类型转换错误ClassCastException,数组索引越界ArrayIndexOutOfBoundsException,使用了空对象NullPointerException等等。
检查异常(checked exception):IOException等其它异常(除了Error 和 RuntimeException的)javac强制要求程序员为这样的异常做预备处理工作(使用try...catch...finally或者throws)。在方法中要么用try-catch语句捕获它并处理,要么用throws子句声明抛出它,否则编译不会通过。这样的异常一般是由程序的运行环境导致的。因为程序可能被运行在各种未知的环境下,而程序员无法干预用户如何使用他编写的程序,于是程序员就应该为这样的异常时刻准备着。如SQLException , IOException,ClassNotFoundException 等。
需要明确的是:检查和非检查是对于javac来说的,这样就很好理解和区分了。
异常是在执行某个函数时引发的,而函数又是层级调用,形成调用栈的,因为,只要一个函数发生了异常,那么他的所有的caller都会被异常影响。当这些被影响的函数以异常信息输出时,就形成的了异常追踪栈。
异常最先发生的地方,叫做异常抛出点。
当devide函数发生除0异常时,devide函数将抛出ArithmeticException异常,因此调用他的CMDCalculate函数也无法正常完成,因此也发送异常,而CMDCalculate的caller——main 因为CMDCalculate抛出异常,也发生了异常,这样一直向调用栈的栈底回溯。这种行为叫做异常的冒泡,异常的冒泡是为了在当前发生异常的函数或者这个函数的caller中找到最近的异常处理程序。由于这个例子中没有使用任何异常处理机制,因此异常最终由main函数抛给JRE,导致程序终止。
如果要自定义异常类,则扩展Exception类即可,因此这样的自定义异常都属于检查异常(checked exception)。如果要自定义非检查异常,则扩展自RuntimeException。
按照国际惯例,自定义的异常应该总是包含如下的构造函数:
- 一个无参构造函数
- 一个带有String参数的构造函数,并传递给父类的构造函数。
- 一个带有String参数和Throwable参数,并都传递给父类构造函数
- 一个带有Throwable 参数的构造函数,并传递给父类的构造函数
- public class IOException extends Exception
- {
- static final long serialVersionUID = 7818375828146090155L;
-
- public IOException()
- {
- super();
- }
-
- public IOException(String message)
- {
- super(message);
- }
-
- public IOException(String message, Throwable cause)
- {
- super(message, cause);
- }
-
-
- public IOException(Throwable cause)
- {
- super(cause);
- }
- }
在 try块中即便有return,break,continue等改变执行流的语句,finally也会执行。
扫码看讲解:
@SneakyThrows
注解的用途得从java的异常设计体系说起。
java中我们常见的2类异常。
1.普通Exception
类,也就是我们常说的受检异常或者Checked Exception。
2.RuntimeException
类,既运行时异常。
前者会强制要求抛出它的方法声明throws,调用者必须显示的去处理这个异常。设计的目的是为了提醒开发者处理一些场景中必然可能存在的异常情况。比如网络异常造成IOException。
但是现实,往往事与愿违。大部分情况下的异常,我们都是一路往外抛了事。(强制处理我也处理不了啊!臣妾做不到)所以渐渐的java程序员处理Exception的常见手段就是外面包一层RuntimeException,接着往上丢。这种解决思想尤其在Spring中到处出现。参见《Spring in Action》
- try{
- }catch(Exception e){
- throw new RuntimeException(e);
- }
Lombok的@SneakyThrows就是为了消除这样的模板代码。
使用注解后不需要担心Exception的处理
- import lombok.SneakyThrows;
-
- public class SneakyThrowsExample implements Runnable {
- @SneakyThrows(UnsupportedEncodingException.class)
- public String utf8ToString(byte[] bytes) {
- return new String(bytes, "UTF-8");
- }
-
- @SneakyThrows
- public void run() {
- throw new Throwable();
- }
- }
真正生成的代码
- import lombok.Lombok;
-
- public class SneakyThrowsExample implements Runnable {
- public String utf8ToString(byte[] bytes) {
- try {
- return new String(bytes, "UTF-8");
- } catch (UnsupportedEncodingException e) {
- throw Lombok.sneakyThrow(e);
- }
- }
-
- public void run() {
- try {
- throw new Throwable();
- } catch (Throwable t) {
- throw Lombok.sneakyThrow(t);
- }
- }
- }
魔法 藏在Lombok.sneakyThrow(t)
中。可能大家都会以为这个方法就是new RuntimeException()之类的。然而事实并非如此。阅读代码可以看出整个方法其实最核心的逻辑是throw (T)t
,利用泛型将我们传入的Throwable强转为RuntimeException。虽然事实上我们不是RuntimeException。但是没关系。因为JVM并不关心这个。泛型最后存储为字节码时并没有泛型的信息。这样写只是为了骗过javac编译器。源码中注释有解释。
- public static RuntimeException sneakyThrow(Throwable t) {
- if (t == null) throw new NullPointerException("t");
- return Lombok.
sneakyThrow0(t); - }
-
- private static
extends Throwable> T sneakyThrow0(Throwable t) throws T { - throw (T)t;
- }