20个异常处理的最佳实践
-
尽量不要 catch RuntimeException，比如 NullPointerException、IndexOutOfBoundsException 等等，应该用预检查的方式来规避。
-
尽量使用 try-with-resource 来关闭资源：禁止在 try 块中直接关闭资源，因为一旦
close()之前发生了异常，那么资源就无法关闭 -
不要捕获 Throwable：很可能把超出程序处理能力之外的错误也捕获了
-
不要省略异常信息的记录
-
不要记录了异常又抛出了异常
-
不要在 finally 块中使用 return：try 块中的 return 语句执行成功后，并不会马上返回，而是继续执行 finally 块中的语句，如果 finally 块中也存在 return 语句，那么 try 块中的 return 就将被覆盖。
private int x = 0;
public int checkReturn() {
try {
return ++x;
} finally {
// try 块中 x 返回的值为 1，到了 finally 块中就返回 2 了
return ++x;
}
}
-
抛出具体定义的检查性异常而不是 Exception
-
捕获具体的子类而不是捕获 Exception 类
-
自定义异常时不要丢失堆栈跟踪
-
finally 块中不要抛出任何异常：如果在 finally 块中抛出异常，可能会导致原始异常被掩盖
-
不要在生产环境中使用
printStackTrace()
- ``printStackTrace()` 方法将异常的堆栈跟踪信息输出到标准错误流中，这可能会暴露敏感信息，如文件路径、用户名、密码等。
printStackTrace()方法会将堆栈跟踪信息输出到标准错误流中，这可能会影响程序的性能和稳定性。在高并发的生产环境中，大量的异常堆栈跟踪信息可能会导致系统崩溃或出现意外的行为。- 由于生产环境中往往是多线程、分布式的复杂系统，
printStackTrace()方法输出的堆栈跟踪信息可能并不完整或准确。
- 对于不打算处理的异常，直接使用 try-finally，不用 catch
- 记住早 throw 晚 catch 原则
- 只抛出和方法相关的异常
- 切勿在代码中使用异常来进行流程控制
- 尽早验证用户输入以在请求处理的早期捕获异常
- 一个异常只能包含在一个日志中
// 反例
log.debug("Using cache sector A");
log.debug("Using retry sector B");
// 正例
// 在多线程环境中，这两行紧挨着的日志代码中间可能会输出很多其他的内容，导致问题查起来会很难受。
LOGGER.debug("Using cache sector A, using retry sector B");
- 将所有相关信息尽可能地传递给异常
- 终止掉被中断线程
// 反例
while (true) {
try {
Thread.sleep(100000);
} catch (InterruptedException e) {} //别这样做
doSomethingCool();
}
// 正例
// 应该尽最大努力完成正在做的事情，并完成当前执行的线程，而不是忽略 InterruptedException
while (true) {
try {
Thread.sleep(100000);
} catch (InterruptedException e) {
break;
}
}
doSomethingCool();
- 对于重复的 try-catch，使用模板方法
