在本文中，作者介绍了9个处理异常的最佳方法与实践，以举例与代码展示结合的方式，让开发者更好的理解这9种方式，并指导读者在不同情况下选择不同的异常处理方式。
以下为译文：
Java中的异常处理不是一个简单的话题。初学者很难理解，甚至有经验的开发人员也会花几个小时来讨论应该如何抛出或处理这些异常。
这就是为什么大多数开发团队都有自己的异常处理的规则和方法。如果你是一个团队的新手，你可能会惊讶于这些方法与你之前使用过的那些方法有多么不同。
然而，有几种异常处理的最佳方法被大多数开发团队所使用。下面是帮助改进异常处理的9个最重要的方法。
1. 在Finally中清理资源或者使用Try-With-Resource语句
通常情况下，你在try中使用了一个资源，比如InputStream，之后需要关闭它。在这种情况下，一个常见的错误是在try的末尾关闭了资源。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
|
问题是，只要不抛出异常，这种方法就可以很好地运行。try内的所有语句都将被执行，资源也会被关闭。
但是你在try里调用了一个或多个可能抛出异常的方法，或者自己抛出异常。这意味着可能无法到达try的末尾。因此，将不会关闭这些资源。
所以应该将清理资源的代码放入Finally中，或者使用Try-With-Resource语句。
使用Finally
相比于try，无论是在成功执行try里的代码后，或是在catch中处理了一个异常后，Finally里的内容是一定会被执行的。因此，可以确保清理所有已打开的资源。
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
Java 7的Try-With-Resource语句
另一个选择是Try-With-Resource语句，在introduction to Java exception handling中更详细地说明了这一点。
如果你的资源实现了AutoCloseable接口，就可以使用它，这正是大多数Java标准资源所做的。当你在try子句中打开资源时，它将在try被执行后自动关闭，或者处理一个异常。
| 1 2 3 4 5 6 7 8 9 10 |
|
2. 给出准确的异常处理信息
你抛出的异常越具体越好。一定要记住，一个不太了解你代码的同事，也许几个月后，需要调用你的方法，并且处理这个异常。
因此，请确保提供尽可能多的信息，这会使你的API更容易理解。因此，你方法的调用者将能够更好地处理异常，或者通过额外的检查来避免它。
所以，要尽量能更好地描述你的异常处理信息，比如用NumberFormatException代替IllegalArgumentException，避免抛出一个不具体的异常。
| 1 2 3 4 5 6 |
|
3. 记录你所指定的异常
当你在方法中指定一个异常时，你应该在Javadoc中记录下它。这与前面提到的方法有着相同的目标：为调用者提供尽可能多的信息，这样他们就可以避免异常或者更容易地处理异常。
因此，请确保在Javadoc中添加一个@throws 声明，并描述可能导致的异常情况。
| 1 2 3 4 5 6 7 8 9 |
|
4. 使用描述性消息抛出异常
这一最佳实践的理念与前两个相似。但这一次，你不用给调用方法的人提供信息。异常消息会被所有人读取，同时必须了解在日志文件或监视工具中报告异常时发生了什么。
因此，应该尽可能准确地描述问题，并提供相关的信息来了解异常事件。
别误会，你不需要写一段文字，而是应该用1-2个简短的句子解释异常的原因。这可以帮助开发团队理解问题的严重性，同时也使你能够更容易地分析任何服务事件。
如果抛出一个特定的异常，它的类名很可能已经描述了这种类型的错误。所以，你不需要提供很多额外的信息。一个很好的例子就是，当你以错误的格式使用字符串时，如NumberFormatException，它就会被类 java.lang.Long的构造函数抛出。
| 1 2 3 4 5 |
|
NumberFormatException已经告诉你问题的类型，所以只需要提供导致问题的输入字符串。如果异常类的名称不具有表达性，那么就需要提供必要的解释信息。
| 1 |
|
5. 最先捕获特定的异常
大多数IDE都可以帮助你做到这点，当你试图捕获不确定的异常时，它会报告一个不可到达的代码块。
问题是只有第一个匹配到异常的catch语句才会被执行，所以，如果你最先发现IllegalArgumentException，你将永远不会到达catch里处理更具体的NumberFormatException，因为它是IllegalArgumentException的一个子类。
所以要首先捕获特定的异常类，并在末尾添加一些处理不是很具体异常的catch语句。
你可以在下面的代码片段中看到这样一个try-catch语句的示例。第一个catch处理所有NumberFormatExceptions异常，第二个catch 处理NumberFormatException异常以外的illegalargumentexception异常。
| 1 2 3 4 5 6 7 8 9 |
|
6. 不要在catch中使用Throwable
Throwable是exceptions 和 errors的父类。当然，你可以在catch子句中使用它，但其实你不应该这样做。
如果你在catch子句中使用Throwable，它将不仅捕获所有的异常，还会捕获所有错误。JVM会抛出错误，这是应用程序不打算处理的严重问题。典型的例子是OutOfMemoryError或StackOverflowError。这两种情况都是由应用程序控制之外的情况引起的，无法处理。
所以，最好不要在catch中使用Throwable，除非你完全确定自己处于一个特殊的情况下，并且你需要处理一个错误。
| 1 2 3 4 5 6 7 |
|
7. 不要忽略Exceptions
你是否曾经分析过只有用例的第一部分才被执行的bug报告吗?
这通常是由一个被忽略的异常引起的。开发人员可能非常确信它不会被抛出，并添加一个无法处理或无法记录它的catch语句。当你发现它的时候，你很可能就会明白一句著名的话“This will never happen”。
| 1 2 3 4 5 6 7 |
|
是的，你可能在分析一个不可能发生的问题。
所以，请千万不要忽略一个例外。你不会知道代码在将来会发生什么变化。有些人可能会删除阻止异常事件的验证，而没有意识到这造成了问题。或者抛出异常的代码被更改，现在抛出了同一个类的多个异常，而调用的代码并不能阻止所有这些异常。
你至少应该写一个日志信息，告诉每个人，需要检查一下这个问题。
| 1 2 3 4 5 6 7 |
|
8. 不要记录和抛出一个异常
这可能是最常被忽略的。你可以在许多代码片段或者库文件里发现，有异常会被捕获、记录和重新抛出。
| 1 2 3 4 5 6 |
|
当它发生时记录一个异常，然后重新抛出它，以便调用者能够适当地处理它，这可能会很直观。但是它会为同一个异常写多个错误消息。
| 1 2 3 4 5 6 7 |
|
不添加任何额外的信息。正如在上述第4个中所解释的那样，异常消息应该描述异常事件。堆栈会告诉你在哪个类、方法和行中异常被抛出。
如果你需要添加额外的信息，应该捕获异常并将其包装在一个自定义的信息中。但要确保遵循下面的第9条。
| 1 2 3 4 5 6 7 |
|
因此，只需要捕获一个你想要处理的异常，在方法中指定它，并让调用者处理它。
9. 包装异常
有时最好捕获一个标准异常并将其封装到一个定制的异常中。此类异常的典型例子是应用程序或框架特定的业务异常。这允许你添加额外的信息，并且也可以为异常类实现一个特殊的处理。
当你这样做时，确保引用原始的异常处理。Exception类提供了一些特定的构造函数方法，这些方法可以接受Throwable作为参数。否则，你将丢失原始异常的堆栈跟踪和消息，这将使你很难分析导致异常的事件。
| 1 2 3 4 5 6 7 |
|
为了让学习变得轻松、高效，今天给大家免费分享一套Java入门教学资源。帮助大家在成为Java架构师的道路上披荆斩棘。需要资料的欢迎加入学习交流群：9285，05736
