异常处理

4月 27 2021 Study>Java 40 分钟 读完 (约 5997 字)

程序运行的时候，经常会发生各种错误。本章我们讨论如何在Java程序中处理各种异常情况。

Java的异常

一个健壮的程序必须能处理各种各样的错误。所谓错误，就是程序调用某个函数的时候，如果失败了就代表出错了。调用方如何获知调用失败的信息？有两种方法：

方法一：约定返回错误码。因为使用int类型的错误码，想要处理就非常麻烦。这种方法常见于底层C函数。

方法二：在语言层面提供一个异常处理机制。Java内置了一套异常处理机制，总是使用异常来表示错误。异常是一种class，因此它本身带有类型信息。异常可以在任何地方抛出，但只需要在上层捕获，这样就和方法调用分离了。

1
2
3
4
5
6
7
8
9
10
11
12
try {
    String s = processFile(“C:\\test.txt”);
    // ok:
} catch (FileNotFoundException e) {
    // file not found:
} catch (SecurityException e) {
    // no read permission:
} catch (IOException e) {
    // io error:
} catch (Exception e) {
    // other error:
}

从继承关系可知，Throwable是异常体系的根，它继承自Object。Throwable有两个体系：Error和Exception，Error表示严重的错误，程序对此一般无能为力，比如：

  • OutOfMemoryError：内存耗尽
  • NoClassDefFoundError：无法加载某个类
  • StackOverflowError：栈溢出

而Exception则是运行时的错误，它可以被捕获并处理。某些异常是应用程序逻辑处理的一部分，应该捕获并处理，例如：

  • NumberFormatException：数值类型的格式错误
  • FileNotFoundException：未找到文件
  • SocketException：读取网络失败

还有一些异常是程序逻辑编写不对造成的，应该修复程序本身。例如：

  • NullPointerException：对某个null对象调用方法或字段
  • IndexOutOfBoundsException：数组索引越界

Exception又分为两大类：RuntimeException以及它的子类，非RuntimeException（包括IOException、ReflectiveOperationException等等）。

Java规定：

  • 必须捕获的异常，包括Exception及其子类，但不包括RuntimeException及其子类，这种类型的异常称为Checked Exception。
  • 不需要捕获的异常，包括Error及其子类，RuntimeException及其子类。

捕获异常

捕获异常使用try...catch语句，把可能发生异常的代码放到try{...}中，然后使用catch捕获对应的Exception及其子类。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Main {
    public static void main(String[] args) {
        byte[] bs = toGBK("中文");
        System.out.println(Arrays.toString(bs));
    }

    static byte[] toGBK(String s) {
        try {
            // 用指定编码转换String为byte[]:
            return s.getBytes("GBK");
        } catch (UnsupportedEncodingException e) {
            // 如果系统不支持GBK编码，会捕获到UnsupportedEncodingException:
            System.out.println(e); // 打印异常信息
            return s.getBytes(); // 尝试使用用默认编码
        }
    }
}

如果我们不捕获UnsupportEncodingException，编译器会报错，报错信息类似于：unreported exception UnsupportedEncodingException; must be caught or declared to be thrown，并且准确地指出需要捕获的语句是return s.getBytes("GBK");。意思是说，像UnsupportedEncodingException这样的Checked Exception，必须被捕获。

这是因为String.getBytes(String)方法定义是：

1
2
3
public byte[] getBytes(String charsetName) throws UnsupportedEncodingException {
    ...
}

于是我们知道，在方法定义的时候，使用throw xxx表示该方法可能抛出的异常类型。调用方在调用时，必须强制捕获这些异常，否则编译器会报错。

在toGBK()方法中，因为调用了String.getBytes(String)方法，就必须捕获UnsupportedEncodingException。我们也可以不捕获它，而是在方法定义处使用throws表示toGBK()方法可能会抛出UnsupportedEncodingException，就可以让toGBK()方法通过编译器检查。

只要是方法声明的Checked Exception，不在调用层捕获，也必须在更高的调用层捕获。所有未捕获的异常，最终也必须在main()方法中捕获，这也是最后捕获Exception的机会。

如果是测试代码，上面的写法就略嫌麻烦。如果不想写任何try代码，可以直接把main()方法定义为throws Exception。因为main()方法声明了可能抛出Exception，也就声明了可能抛出的所有Exception，因此在内部就无需捕获了。代价就是一旦发生异常，程序会立刻退出。

还有一些同学喜欢捕获异常后不处理，这种方式是非常不好的，即使什么也做不了，也要把异常都记下来。所有异常都可以调用printStackTrace()方法打印异常栈，这是一个简单快速打印异常栈的方法。

多catch语句

可以使用多个catch语句，每个catch分别捕获对应的Exception及其子类。JVM在捕获到异常后，会从上到下匹配catch语句，匹配到某个catch后，执行catch代码块，然后不在继续匹配。简单地说就是，多个catch语句只有一个能被执行。

因此，存在多个catch语句时，catch的顺序非常重要，子类必须写在前面。

finally语句

无论是否有异常发生，我们都希望执行一些语句，例如清理工作，怎么写？

Java的try…catch机制还提供了finally语句，finally语句块保证有无错误都会执行。

finally有以下几个特点：

  • finally语句不是必须的
  • finally总是最后执行

如果没有发生异常，就正常执行try语句块，然后执行finally。如果发生了异常，就中断执行try语句块，然后跳转执行匹配的catch语句块，最后执行finally。可见，finally用来保证一些代码必须执行。

某些情况下，例如方法声明了可能抛出的异常，可以没有catch，只使用try…finally结构。

捕获多种异常

如果某些异常的处理逻辑相同，但是异常本身不存在继承关系，那么就得编写多条catch子句。但也可以用|把处理逻辑相同的异常合并到一起，就像这样。

1
2
3
4
5
6
7
8
9
10
11
public static void main(String[] args) {
    try {
        process1();
        process2();
        process3();
    } catch (IOException | NumberFormatException e) { // IOException或NumberFormatException
        System.out.println("Bad input");
    } catch (Exception e) {
        System.out.println("Unknown error");
    }
}

抛出异常

异常的传播

当某个方法抛出了异常时，如果当前方法没有捕获异常，异常就会被抛到上层调用方法，直到遇到某个try…catch被捕获为止。

抛出异常

当发生错误时，例如，用户输入了非法的字符，我们就可以抛出异常。如何抛出异常？分两步：

  1. 创建某个Exception类
  2. 用throw语句抛出
1
2
3
4
5
6
void process2(String s) {
    if (s==null) {
        NullPointerException e = new NullPointerException();
        throw e;
    }
}

实际上，绝大部分抛出异常的代码都会合并写到一行：

1
2
3
4
5
void process2(String s) {
    if (s==null) {
        throw new NullPointerException();
    }
}

如果一个方法捕获了某个异常后，又在catch子句中抛出新的异常，就相当于把抛出的异常类型“转换”了。

为了能追踪到完整的异常栈，在构造异常时，把原始的Exception实例传进去，新的Exception就可以持有原始Exception信息。

有了完整的异常栈的信息，我们才能快速定位并修复代码的问题。捕获到异常并再次抛出时，一定要留住原始异常，否则很难定位第一案发现场！

在代码中获取原始异常可以使用Throwable.getCause()方法，如果返回null，说明已经是“根异常”了。

异常屏蔽

如果在执行finally语句时抛出异常，那么catch语句的异常还能否继续抛出？finally抛出异常后，原来在catch中准备抛出的异常就“消失”了，因为只能抛出一个异常，没有被抛出的异常称为“被屏蔽”的异常（Suppressed Exception）。

在极少数情况下，我们需要获知所有的异常。如何保存所有的异常信息？方法是先用origin变量保存原始异常，然后调用Throwable.addSuppressed()，把原始异常添加进来，最后在finally抛出。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Main {
    public static void main(String[] args) throws Exception {
        Exception origin = null;
        try {
            System.out.println(Integer.parseInt("abc"));
        } catch (Exception e) {
            origin = e;
            throw e;
        } finally {
            Exception e = new IllegalArgumentException();
            if (origin != null) {
                e.addSuppressed(origin);
            }
            throw e;
        }
    }
}

当catch和finally都抛出了异常时，虽然catch的异常被屏蔽了，但是finally抛出的异常仍然包含了它。

绝大多数情况下，在finally中不要抛出异常，通常不需要关心Suppressed Exception。

提问时贴出异常

异常打印的栈信息是找出问题的关键，许多初学者提问时只贴代码不贴异常，相当于只报案不给线索，福尔摩斯也无能为力。还有同学只贴部分异常信息，最关键的Caused by: xxx给省略了，这都属于不正确的提问方式，得改。

自定义异常

Java标准库定义的常用异常包括：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
Exception
│
├─ RuntimeException
│  │
│  ├─ NullPointerException
│  │
│  ├─ IndexOutOfBoundsException
│  │
│  ├─ SecurityException
│  │
│  └─ IllegalArgumentException
│     │
│     └─ NumberFormatException
│
├─ IOException
│  │
│  ├─ UnsupportedCharsetException
│  │
│  ├─ FileNotFoundException
│  │
│  └─ SocketException
│
├─ ParseException
│
├─ GeneralSecurityException
│
├─ SQLException
│
└─ TimeoutException

当我们在代码中需要抛出异常时，尽量使用JDK已定义的异常类型。

在一个大型项目中，可以自定义新的异常类型，但是保持一个合理的异常继承体系是非常重要的。

一个常见的做法是自定义一个BaseException作为根异常，然后派生出各种业务类型的异常。BaseExcption需要从一个合适的Exception派生，通常建议从RuntimeException派生。

1
2
public class BaseException extends RuntimeException{
}

其他业务类型的异常就可以从BaseException派生。

1
2
3
4
5
6
7
public class UserNotFoundException extends BaseException {
}

public class LoginFailedException extends BaseException {
}

...

自定义的BaseException应该提供多个构造方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class BaseException extends RuntimeException {
    public BaseException() {
        super();
    }

    public BaseException(String message, Throwable cause) {
        super(message, cause);
    }

    public BaseException(String message) {
        super(message);
    }

    public BaseException(Throwable cause) {
        super(cause);
    }
}

这样，抛出异常的时候，就可以选择合适的构造方法。

NullPointerException

在所有的RuntimeException异常中，Java程序员最熟悉的恐怕就是NullPointerException了。NullPointerException俗称NPE，即空指针异常。如果一个对象是null，调用其方法或访问其字段就会产生NullPointerException，这个异常通常是由JVM抛出的。

指针这个概念实际上源自C语言，Java语言中并无指针。我们定义的变量实际上是引用，Null Pointer更确切地说是Null Reference，不过两者区别不大。

处理NullPointerException

首先，必须明确，NullPointerException是一种代码逻辑错误，遇到NullPointerException，遵循原则是早暴露，早修复，严禁使用catch来隐藏这种编码错误。

好的编码习惯可以极大地降低NullPointerException的产生，例如，成员变量在定义时初始化：

1
2
3
public class Person {
    private String name = "";
}

使用空字符串""而不是默认的null可避免很多NullPointerException，编写业务逻辑时，用空字符串""表示未填写比null安全得多。

定位NullPointerException

如果产生了NullPointerException，例如，调用a.b.c.x()时产生了NullPointerException，原因可能是：

  • a是null
  • a.b是null
  • a.b.c是null

确定到底是哪个对象是null以前只能打印这样的日志：

1
2
3
System.out.println(a);
System.out.println(a.b);
System.out.println(a.b.c);

从Java 14开始，如果产生了NullPointerException，JVM可以给出详细的信息告诉我们null对象到底是谁。

使用断言

断言（Assertion）是一种调试程序的方式。在Java中，使用assert关键字来实现断言。先看一个栗子：

1
2
3
4
5
public static void main(String[] args) {
    double x = Math.abs(-123.45);
    assert x >= 0;
    System.out.println(x);
}

语句assert x >= 0;即为断言，断言条件x >= 0预期为true。如果计算结果为false，则断言失败，抛出AssertionError。

使用assert语句时，还可以添加一个可选的断言消息：assert x >= 0 : "x must >= 0";。这样，断言失败的时候，AssertionError会带上消息x must >= 0，更加便于调试。

Java断言的特点是：断言失败时会抛出AssertionError，导致程序结束退出。因此，断言不能用于可恢复的程序错误，只应用于开发和测试阶段。

JVM默认关闭断言指令，即遇到assert语句就自动忽略了。要执行assert语句，必须给Java虚拟机传递-enableassertions（简写为-ea）参数启用断言。

还可以有选择地对特定地类启用断言，命令行参数是：-ea:com.itranswarp.sample.Main，表示只对com.itranswarp.sample.Main这个类启用断言。

或者对特定地包启用断言，命令行参数是：-ea:com.itranswarp.sample...（注意结尾有3个.），表示对com.itranswarp.sample这个包启动断言。

实际开发中，很少使用断言。更好的方法是编写单元测试，后续我们会讲解JUnit的使用。

使用JDK Logging

什么是日志？日志就是Logging，它的目的是为了取代System.out.println()。输出日志，而不是用System.out.println()，有以下几个好处：

  • 可以设置输出样式，避免每次都写"Error: "+var
  • 可以设置输出级别，禁止某些级别输出。例如，只输出错误日志。
  • 可以被重定向到文件，这样可以在程序运行结束后查看日志
  • 可以按包名控制日志级别，只输出某些包打的日志
  • …

Java标准库内置了日志包java.util.logging，我们可以直接用。使用日志最大的好处是，它自动打印了时间、调用类、调用方法等很多有用的信息。

JDK的Logging定义了七个日志级别，从严重到普通：

  • SEVERE
  • WARNING
  • INFO
  • CONFIG
  • FINE
  • FINER
  • FINEST

默认级别是INFO，因此INFO级别以下的日志不会被打印出来。使用日志级别的好处在于，调整级别就可以屏蔽掉很多调试相关的日志输出。

使用Java标准库内置的Logging有以下局限：

  • Logging系统在JVM启动时读取配置文件并完成初始化，一旦开始运行main()方法，就无法修改配置
  • 配置不太方便，需要在JVM启动时传递参数-Djava.util.logging.config.file=<config-file-name>。

因此，Java标准库内置的Logging使用并不是很广泛。更方便的日志系统我们稍后介绍。

使用Commons Logging

和Java标准库提供的日志不同，Commons Logging是一个第三方日志库，它是由Apache创建的日志模块。

Commons Logging的特点是，它可以通过配置文件指定挂接的日志系统。默认情况下，Commons Logging自动搜索并使用Log4j（Log4j是另一个流行的日志系统），如果没有找到Log4j，再使用JDK Logging。

使用Commons Logging只需要和两个类打交道，并且只有两步：

  1. 通过LogFactory获取Log类的实例
  2. 使用Log实例的方法打日志

Commons Logging定义了6个日志级别：

  • FATAL
  • ERROR
  • WARNING
  • INFO
  • DEBUG
  • TRACE

默认级别是INFO。

使用Commons Logging时，如果在静态方法中引用Log，通常直接定义一个静态变量。在实例方法中引用Log，通常定义一个实例变量。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
// 在静态方法中引用Log:
public class Main {
    static final Log log = LogFactory.getLog(Main.class);
    static void foo() {
        log.info("foo");
    }
}

// 在实例方法中引用Log:
public class Person {
    protected final Log log = LogFactory.getLog(getClass());
    void foo() {
        log.info("foo");
    }
}

// 在子类中使用父类实例化的log:
public class Student extends Person {
    void bar() {
        log.info("bar");
    }
}

注意到实例变量log的获取方式是LogFactory.getLog(getClass())，虽然也可以用LogFactory.getLog(Person.class)，但是前一种方式有个非常大的好处，就是子类可以直接使用该log实例。

由于Java类的动态特性，子类获取的log字段实际上相当于LogFactory.getLog(Student.class)，但却是从父类继承而来，并且无需改动代码。

此外，Commons Logging的日志方法，例如info()，除了标准的info(String)，还提供了一个非常有用的重载方法：info(String, Throwable)，这使得记录异常更加简单。

使用Log4j

前面介绍了Commons Logging，可以作为“日志接口”来使用，而真正的“日志实现”可以使用Log4j。Log4j是一种非常流行的日志框架。Log4j是一个组件化设计的日志系统，它的架构大致如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
log.info("User signed in.");
 │
 │   ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
 ├──>│ Appender │───>│  Filter  │───>│  Layout  │───>│ Console  │
 │   └──────────┘    └──────────┘    └──────────┘    └──────────┘
 │
 │   ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
 ├──>│ Appender │───>│  Filter  │───>│  Layout  │───>│   File   │
 │   └──────────┘    └──────────┘    └──────────┘    └──────────┘
 │
 │   ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
 └──>│ Appender │───>│  Filter  │───>│  Layout  │───>│  Socket  │
     └──────────┘    └──────────┘    └──────────┘    └──────────┘

当我们用Log4j输出一条日志时，Log4j自动通过不同的Appender把同一条日志输出到不同的目的地。例如：

  • console：输出到屏幕
  • file：输出到文件
  • socket：通过网络输出到远程计算机
  • jdbc：输出到数据库

在输出日志的过程中，通过Filter来过滤哪些log需要被输出，哪些log不需要被输出。例如，仅输出ERROR级别的日志。

最后通过Layout来格式化日志信息，例如，自动添加日期、时间、方法名称等。

上述结构虽然复杂，但我们在实际使用时，并不需要关心Log4j的API，而是通过配置文件来配置它。以XML配置为例，使用Log4j时，我们把一个log4j2.xml文件放到classpath下就可以让Log4j读取配置文件并按照我们的配置来输出日志。下面是一个配置文件的例子。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
	<Properties>
        <!-- 定义日志格式 -->
		<Property name="log.pattern">%d{MM-dd HH:mm:ss.SSS} [%t] %-5level %logger{36}%n%msg%n%n</Property>
        <!-- 定义文件名变量 -->
		<Property name="file.err.filename">log/err.log</Property>
		<Property name="file.err.pattern">log/err.%i.log.gz</Property>
	</Properties>
    <!-- 定义Appender，即目的地 -->
	<Appenders>
        <!-- 定义输出到屏幕 -->
		<Console name="console" target="SYSTEM_OUT">
            <!-- 日志格式引用上面定义的log.pattern -->
			<PatternLayout pattern="${log.pattern}" />
		</Console>
        <!-- 定义输出到文件,文件名引用上面定义的file.err.filename -->
		<RollingFile name="err" bufferedIO="true" fileName="${file.err.filename}" filePattern="${file.err.pattern}">
			<PatternLayout pattern="${log.pattern}" />
			<Policies>
                <!-- 根据文件大小自动切割日志 -->
				<SizeBasedTriggeringPolicy size="1 MB" />
			</Policies>
            <!-- 保留最近10份 -->
			<DefaultRolloverStrategy max="10" />
		</RollingFile>
	</Appenders>
	<Loggers>
		<Root level="info">
            <!-- 对info级别的日志，输出到console -->
			<AppenderRef ref="console" level="info" />
            <!-- 对error级别的日志，输出到err，即上面定义的RollingFile -->
			<AppenderRef ref="err" level="error" />
		</Root>
	</Loggers>
</Configuration>

虽然配置Log4j比较繁琐，但一旦配置完成，使用起来就非常方便。对上面的配置文件，凡是INFO级别的日志，会自动输出到屏幕，而ERROR级别的日志，不但会输出到屏幕，还会同时输出到文件。并且，一旦日志文件达到指定大小（1MB），Log4j就会自动切割新的日志文件，并最多保留10份。

在开发阶段，始终使用Commons Logging接口来写入日志，并且开发阶段无需引入Log4j。如果需要把日志写入文件， 只需要把正确的配置文件和Log4j相关的jar包放入classpath，就可以自动把日志切换成使用Log4j写入，无需修改任何代码。

使用SLF4J和Logback

前面介绍了Commons Logging和Log4j这一对好基友，一个负责充当日志API，一个负责实现日志底层，搭配使用非常方便开发。有的童鞋可能还听说过SLF4J和Logback。SLF4J类似于Commons Logging，也是一个日志接口，而Logback类似于Log4j，是一个日志的实现。

为什么有了Commons Logging和Log4j，又会蹦出来SLF4J和Logback？这是因为Java有着非常悠久的开源历史，不但OpenJDK本身是开源的，而且我们用到的第三方库，几乎全部都是开源的。开源生态丰富的一个特定就是，同一个功能，可以找到若干种互相竞争的开源库。因为对Commons Logging的接口不满意，有人就搞了SLF4J。因为对Log4j的性能不满意，有人就搞了Logback。

我们先来看看SLF4J对Commons Logging的接口有何改进。在Commons Logging中，我们要打印日志，有时候得这么写：

1
2
3
int score = 99;
p.setScore(score);
log.info("Set score " + score + " for Person " + p.getName() + " ok.");

拼字符串是一个非常麻烦的事，所以SLF4J的日志接口改成了这样：

1
2
3
int score = 99;
p.setScore(score);
logger.info("Set score {} for Person {} ok.", score, p.getName());

我们靠猜也能猜出来，SLF4J的日志接口传入的是一个带占位符的字符串，用后面的变量自动替换占位符，看起来更自然。

如何使用SLF4J呢？它的接口实际上和Commons Logging几乎一模一样。对比一下二者的接口。

Commons Logging SLF4J
org.apache.commons.logging.Log org.slf4j.Logger
org.apache.commons.logging.LogFactory org.slf4j.LoggerFactory

和Log4j类似，我们仍然需要一个Logback的配置文件，把logback.xml放到classpath下，配置如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
<?xml version="1.0" encoding="UTF-8"?>
<configuration>

	<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
		<encoder>
			<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
		</encoder>
	</appender>

	<appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
		<encoder>
			<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
			<charset>utf-8</charset>
		</encoder>
		<file>log/output.log</file>
		<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
			<fileNamePattern>log/output.log.%i</fileNamePattern>
		</rollingPolicy>
		<triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
			<MaxFileSize>1MB</MaxFileSize>
		</triggeringPolicy>
	</appender>

	<root level="INFO">
		<appender-ref ref="CONSOLE" />
		<appender-ref ref="FILE" />
	</root>
</configuration>

从目前的趋势来看，越来越多的开源项目从Commons Logging加Log4j转向了SLF4J加Logback。

反射 Java核心类
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×