一、在 Finally 中清理资源或使用 Try-With-Resource 语句

在实际开发中会经常遇到在 try 中使用资源的情况，比如一个 InputStream ，在使用后你需要关闭它。在这种情况下，一个常见的错误是在 try 的尾部关闭了资源。

public void doNotCloseResourceInTry() {

FileInputStream inputStream = null; try { File file = new File("./tmp.txt");

inputStream = new FileInputStream(file); // use the inputStream to read a file

// do NOT do this

inputStream.close();

} catch (FileNotFoundException e) {

log.error(e);

} catch (IOException e) {

log.error(e);

}

}

这种情况的问题是，只要异常没被抛出，程序就能很好地运行。所有在 try 中的代码都将被正常执行，资源也会被关闭。

但是，用 try 总是有原因的。当你调用一个或多个可能会抛出异常的方法或自己主动抛出异常时，程序可能会无法到达 try 的尾部。于是在最后，资源将不被关闭。

因为，你应该将所有清理资源的代码放进 finally 中，或使用 try-with-resource 语句。

使用 Finally

与 try 相比，无论是 try 中的代码被成功执行，还是在 catch 中处理了一个异常后，Finally 中的代码总会被执行。因此，你可以确保所有已打开的资源都将被关闭。

public void closeResourceInFinally() {

FileInputStream inputStream = null; try { File file = new File("./tmp.txt");

inputStream = new FileInputStream(file); // use the inputStream to read a file

} catch (FileNotFoundException e) {

log.error(e);

} finally { if (inputStream != null) { try {

inputStream.close();

} catch (IOException e) {

log.error(e);

}

}

}

}

Java 7 的 Try-With-Resource 语句

你还可以选择 try-with-resource 语句，在我的这篇 Java 异常处理入门 中有更为详细的介绍。

如果你在资源中实现了 AutoCloseable 接口的话，就可以使用 try-with-resource 语句了，这也是大多数 Java 标准资源的做法。如果你在 try-with-resource 中打开了一个资源，在 try 中的代码被执行或异常处理后，这个资源将会被自动关闭。

public void automaticallyCloseResource() { File file = new File("./tmp.txt"); try (FileInputStream inputStream = new FileInputStream(file);) { // use the inputStream to read a file

} catch (FileNotFoundException e) {

log.error(e);

} catch (IOException e) {

log.error(e);

}

}

二、抛出更具体的异常

你抛出的异常越具体、越明确越好。时刻牢记这点，特别是如果有一位并不了解你代码的同事，或几个月后的你需要调用自己的方法并处理异常时。

因此，你需要确保提供尽可能多的信息，这会使得你的 API 更易于理解。这样，调用你方法的人可以更好地处理异常，从而避免额外的诸如 此类的检查 。

所以，应该找到与你的异常事件最符合的类，比如抛出一个 NumberFormatException 而不是 IllegalArgumentException (注：例如将参数转换为数值出错时，应该抛出具体的 NumberFormatException ，而不是笼统的 IllegalArgumentException )。请避免抛出一个不具体的异常。

public void doNotDoThis() throws Exception {

...

}public void doThis() throws NumberFormatException {

...

}

三、为你的异常编写文档

当你在方法签名中 指定一个异常 时，你也应该在 Javadoc 中记录它 。

所以，请确保在 Javadoc 中增加 @throws 声明，并描述可能会导致异常的情况。

/**

* This method does something extremely useful ...

*

* @param input

* @throws MyBusinessException if ... happens

*/public void doSomething(String input) throws MyBusinessException {

...

}

四、将描述信息与异常一同抛出

这个方法背后的思想和前两个是类似的。但这一次，你不必给你的方法调用者提供信息。对于任何遭遇异常错误并需要搞清楚错误原因的人来说，异常信息总是在异常出现的同时，被记录在了日志中，或打印在了屏幕上。

因此，请尽可能精确地描所以，最好不要在 catch 中使用 Throwable ，除非你能确保自己处于一些特定情况下，比如你自己足以处理错误，又或被要求处理错误时。述异常事件，并提供最相关的信息以令其他人能够理解发生了什么异常时。

别误会我的意思了。你没必要去写上一大段的文字，但你应该用一两句简短的话来解释一下异常发生的原因。这能让你的开发团队明白问题的严重性，也能让你更容易地分析服务事故。

如果你抛出了一个特定的异常，它的类名很可能就已经描述了这是什么类型的错误了。所以，你不需要提供很多额外的描述信息。一个很好的例子是，当你提供了一个错误格式的 String 类型参数时，java.lang.Long 构造函数就会抛出 NumberFormatException 。

try {

new Long("xyz");

} catch (NumberFormatException e) {

log.error(e);

}

NumberFormatException 的类名已经告诉了你问题的类型。所以异常信息只需要返回导致问题的输入字符串就行了。如果异常类的名字不能表明其含义，那么你还需要在异常信息中提供必要的解释信息。

17:17:26,386 ERROR TestExceptionHandling:52 - java.lang.NumberFormatException: For input string: "xyz"

五、优先捕获具体的异常

大多数 IDE 都能帮你做到这点。当你尝试优先捕获不那么具体的异常时， IDE 会报告给你这是一个不能到达的代码块。

这个问题的原因是只有第一个匹配到异常的 catch 块才会被执行。所以，如果你先 catch 了一个 IllegalArgumentException ，你将永远无法到达处理更具体异常 NumberFormatException 的 catch 块中，因为 NumberFormatException 是 IllegalArgumentException 的子类。

所以，请优先捕获更具体的异常，并把不那么具体的 catch 块放在后面。

在下面你可以看到这样的一个 try-catch 语句示例。第一个 catch 处理所有的 NumberFormatExceptions 异常，第二个 catch 处理 NumberFormatException 异常以外的 illegalargumentexception 异常。

public void catchMostSpecificExceptionFirst() { try {

doSomething("A message");

} catch (NumberFormatException e) { log.error(e);

} catch (IllegalArgumentException e) { log.error(e)

}

}

六、不要捕获 Throwable

Throwable 是所有 exceptions 和 errors 的父类。虽然你可以在 catch 子句中使用它，但你应该永远别这样做！

如果你在 catch 子句中使用了 Throwable ，它将不仅捕获所有异常，还会捕获所有错误。这些错误是由 JVM 抛出的，用来表明不打算由应用处理的严重错误。 OutOfMemoryError 和 StackOverflowError 就是典型的例子，这两种情况都是由一些超出应用控制范围的情况导致的，无法处理。

所以，最好不要在 catch 中使用 Throwable ，除非你能确保自己处于一些特定情况下，比如你自己足以处理错误，又或被要求处理错误。

public void doNotCatchThrowable() { try { // do something

} catch (Throwable t) { // don't do this!

}

}

七、不要忽略异常

你分析过只有用例的第一部分代码被执行的 bug 报告吗？

这通常是由于忽略异常而导致的。开发者可能十分确定这个异常不会被抛出，然后添加了一个无法处理或无法记录这个异常的 catch 。当你找到这个 catch 时，你很可能会发现这么一句著名的注释： “This will never happen”。

public void doNotIgnoreExceptions() { try { // do something

} catch (NumberFormatException e) { // this will never happen

}

}

没错，你可能就是在分析一个永远也不会发生的问题。

所以，请你务必不要忽略异常。你不知道代码在将来会经历怎样的改动。有些人可能会误删异常事件的验证，而完全没意识到这会产出问题。或者抛出异常的代码被修改了，相同的类被抛出了多个异常，而调用它们的代码并不能阻止这些异常发生。

你至少应该把日志信息打印出来，告诉那些无意识下错误操作的人需要检查这里。

public void logAnException() { try { // do something

} catch (NumberFormatException e) { log.error("This should never happen: " + e);

}

}

八、不要同时打印并抛出异常

这可能是本文中最常被忽略的一条实践准则了。你可以在许多代码片段甚至库中发现这个问题，异常被捕获，打印，再被重新抛出。

try { new Long("xyz");

} catch (NumberFormatException e) { log.error(e); throw e;

}

这样也许会很直观地看到被打印的异常，异常再被重新抛出，调用者也能很好地处理它。但这样会使多个错误信息被同个异常给打印出来。

17:44:28,945 ERROR TestExceptionHandling:65 - java.lang.NumberFormatException: For input string: "xyz"Exception in thread "main" java.lang.NumberFormatException: For input string: "xyz"at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)at java.lang.Long.parseLong(Long.java:589)at java.lang.Long.(Long.java:965)at com.stackify.example.TestExceptionHandling.logAndThrowException(TestExceptionHandling.java:63)at com.stackify.example.TestExceptionHandling.main(TestExceptionHandling.java:58)

额外的信息并不能提供更多的错误细节。如第4条准则中所述，异常信息应该准确描述异常事件。 Stack Trace (堆栈追踪)会告诉你异常在哪个类、哪个方法、哪个行中被抛出。

如果你需要添加额外的信息，你应该将异常捕获并包装在自定义的的异常中，但要确保遵循下面的第9条实践准则。

public void wrapException(String input) throws MyBusinessException { try { // do something

} catch (NumberFormatException e) { throw new MyBusinessException("A message that describes the error.", e);

}

}

所以，只有在你想要处理一个异常的时候才去捕获它。否则，在方法签名处指明这个异常让调用者关注就好了。

九、包装异常但不要丢弃原始异常

有时候将异常包装成一个自定义异常会比捕捉一个标准异常要更好。一个典型的例子是应用或框架的特定业务异常。这允许你添加额外的信息，也能为你的异常类实现一个特定的处理方法。

当你这么做的时候，一定要确保原始的异常设为 cause 。 Exception 类提供了一系列的特定构造方法，这些方法可以接受 Throwable 作为参数(注：如 Exception(String message, Throwable cause) )。否则，你将会丢失原始异常的 stack trace 与信息，这会使你分析导致异常的事件变得十分困难。

public void wrapException(String input) throws MyBusinessException { try { // do something

} catch (NumberFormatException e) { throw new MyBusinessException("A message that describes the error.", e);

}

}

总结

如你所见，当决定该抛出还是捕获异常时候，你需要去考虑很多方面。以上的大多数实践准则都是为了提高你代码和 API 的可读性与可用性。

异常是不仅是一个错误处理机制，同时也是一个沟通媒介。因此，你应该与你的同事一起讨论哪些是你想要应用的最佳实践与准则，以便所有人都能理解相关的基本概念，并用同样的方式在实际中应用这些准则。

Java高架构师、分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频免费获取架构群：854180697    加群链接

写在最后：欢迎留言讨论，点“关注”，不迷路，加关注，持续更新！