Java异常良好实践

- 日理万妓 2023-10-12 11:11 94阅读 0赞

### 前言 ###

在[字节码层面学习Java异常底层原理][Java]一文中，对**Java**的异常体系和异常原理进行了学习，但是最后并没有总结出异常实践，本文将结合实际的开发经验，以及阿里巴巴开发手册中对异常的一些约束，给出一个具有一定参考意义的异常良好实践，希望能够帮助大家。

但是有一点需要注意，所谓的良好实践，也只是在特定场景下的一种异常使用方式，大多数时候都难以具有普适性，举个简单例子，可能你们公司的大佬告诉你不要捕获**Exception**，不要捕获**Throwable**，但是实际情况我们就是需要有一个对异常的兜底策略，而往往这个策略就是需要捕获一个最顶层的异常基类，你去看一些大名鼎鼎的开源项目，例如**MyBatis**，**Tomcat**等，别人一样在一些地方捕获了**Exception**，捕获了**Throwable**，你能说别人写得差吗，不能的吧。

所以有没有一种可能，叫你不要捕获**Exception**，不要捕获**Throwable**的大佬，很久没写过代码了。

### 正文 ###

#### 一. 不要使用异常做流程控制 ####

业务代码应该和异常处理代码解耦，不应该将异常的捕获和处理用在业务代码的流程控制中，比如下面的代码就是十足的坏味道。

java

复制代码

`public class BadTasteTest { @Test public void 异常控制业务流程() { Demo demo = null; // 一系列逻辑 ...... try { demo.report(); } catch (NullPointerException e) { doWhenDemoNull(); } } private void doWhenDemoNull() {} private static class Demo { public void report() {} } }`

要修复上面的坏味道，就是把异常从业务流程中去除，如下所示。

java

复制代码

`@Test public void 异常控制业务流程_修复() { Demo demo = null; // 一系列逻辑 ...... if (demo == null) { doWhenDemoNull(); } else { demo.report(); } }`

#### 二. 不要滥用校验异常 ####

校验异常能够**强迫**应用程序去处理，要么使用**try-catch**捕获，要么使用**throw**向上层抛出，这增强了代码的健壮性，但是校验异常也有许多缺点，如下所示。

1.  **无法做到无感**。调用一个会抛出校验异常的方法，我们会被强迫去判断抛出的异常是需要处理还是需要再往上层抛出，如果有大量方法滥用校验异常，每个方法我们都需要判断，增加我们的编程负担；
2.  **Lambda**表达式支持不好。主要体现于如果在**Lambda**表达式中调用了会抛出校验异常的方法，那么只能在调用方法的地方进行**try-catch**，而不能向上层抛出。

#### 三. RuntimeException尽量不捕获 ####

这里的**RuntimeException**指的是类似于**NullPointerException**，**ClassCastException**这种预置的**RuntimeException**，这些运行时异常尽量不采用捕获的方式去处理，而是对可能会抛出这些运行时异常的代码进行预判断来防止异常抛出。

例如可能会抛出**NullPointerException**的地方，预先进行判空，如下所示。

java

复制代码

`if (result != null) { return result.data; }`

例如可能会抛出**ClassCastException**的地方，预先进行类型判断，如下所示。

java

复制代码

`if (obj instanceof Report) { return ((Report) obj).result; }`

#### 四. 建议自定义RuntimeException异常 ####

如果在应用程序中有自定义异常的需求，建议自定义异常继承于**RuntimeException**，此时我们实现的自定义异常就是运行时异常，属于非校验异常，因此不需要在代码中到处捕获或抛出，我们可以在能够处理这个自定义异常或者在异常处理中心统一进行处理。

当然，这么做的原因就是为了代码的整洁，如果我们自定义的异常真的十分重要，一定要处处都感知到这个自定义异常，那么还是可以继承于**Exception**。

在**MyBatis**中，所有的自定义异常都是**RuntimeException**。

#### 五. 多用try-with-resources来处理资源关闭 ####

对于需要关闭资源的场景，尽量使用**try-with-resources**来实现，这么做的理由如下。

1.  **代码简洁**。不需要自己在**finally**中写一大堆代码来关闭资源；
2.  **异常抑制**。**try-with-resources**帮我们实现了异常抑制的语法糖。

使用案例如下。

java

复制代码

`try (Connection connection = new Connection()) { connection.update(); }`

#### 六. 尽量不要在finally中抛出异常 ####

因为直接在**finally**中抛出异常会发生**异常屏蔽**的问题，虽然通过改写代码能够解决异常屏蔽，但是写起来十分复杂，所以如果一定要在**finally**中抛出异常，可以选择使用**try-with-resources**。

#### 七. 一定要正确包装异常信息 ####

当我们捕获一个特定异常并且需要将这个异常包装成另外一个异常时，一定不能丢掉被包装异常的信息。

如下是一个反例。

java

复制代码

`catch (SQLException e) { throw new MySQLException("Additional information " + e.getMessage()); }`

抛出去的**MySQLException**丢失了原始异常**SQLException**的大部分信息，应该修改如下。

java

复制代码

`catch (SQLException e) { throw new MySQLException("Additional information ", e); }`

#### 八. 不要泛滥的捕获Exception ####

**Exception**并非不可以捕获，但是不能在代码中过度的捕获**Exception**，因为一旦对当前代码块捕获**Exception**，将会丢失当前代码块会发生的异常信息，最终我们就不知道这个代码块会发生何种类型的异常了，最终只能在正真发生异常时通过日志去定位。

如下就是一个十足的捕获**Exception**的坏味道的代码。

java

复制代码

`public void controllerMethod() { try { serviceMethod(); } catch (Exception e) { LOGGER.error("发生了异常", e); } } public void serviceMethod() { // 业务代码 // 这里可能会抛出ServiceException ... try { daoMethod(); } catch (Exception e) { LOGGER.error("发生了异常", e); } } private void daoMethod() { // 业务代码 // 这里可能会抛出DaoException ...... try { // 数据库操作 ...... } catch (Exception e) { LOGGER.error("发生了异常", e); } finally { // 关闭资源 // 事务回滚 ...... } }`

可以进行如下改进。

java

复制代码

`public void controllerMethod() { try { serviceMethod(); } catch (ServiceException e) { LOGGER.error("发生SERVICE了异常", e); } catch (Exception e) { LOGGER.error("发生了未知异常", e); } } public void serviceMethod() { // 业务代码 // 这里可能会抛出ServiceException ... try { daoMethod(); } catch (DaoException e) { LOGGER.error("发生了DAO层异常", e); } } private void daoMethod() { // 业务代码 // 这里可能会抛出DaoException ...... try { // 数据库操作 ...... } catch (SQLException e) { LOGGER.error("发生了SQL异常", e); } finally { // 关闭资源 // 事务回滚 ...... } }`

#### 九. 不要吞掉异常 ####

意思就是不要捕获异常后什么事情都不做，就像下面这样。

java

复制代码

`try { // 业务代码 ..... } catch(SQLException e) { LOGGER.error("发生了SQL异常", e); } catch(Exception e) { // 什么事情都不做 }`

#### 十. 尽量不要捕获Throwable或者Error ####

主要就是尽量不要捕获**Error**，因为一旦发生**Error**，表明程序发生了程序无法修复的问题，这些问题就比如内存溢出问题，或者因为依赖问题导致的找不到某个方法某个字段等，我们需要做的就是让**Error**一路外抛，直到某一层能明确将这个**Error**暴露出来为止。

### 总结 ###

请一定记住，所谓的异常良好实践，最终都会落到具体情况具体分析，如果在业务代码中处处都严格遵循异常的一些使用规则，那么最终写出来的代码，不一定是业务友好的代码。

[Java]: https://juejin.cn/post/7238195267287531579