java大量抛出异常_处理Java异常的9个最佳实践

原标题：处理Java异常的9个最佳实践

原创于【模棱博客】 http://www.flammulina.com

Java中的异常处理不是一个简单的主题。初学者发现很难理解，甚至有经验的开发人员也可以花几个小时讨论如何以及应该抛出或处理哪些Java异常。

这就是为什么大多数开发团队都有自己的如何使用它们的规则。如果你是一个团队的新手，你可能会惊讶于这些规则与你之前使用过的规则有多么不同。

尽管如此，大多数团队都使用了几种最佳实践。以下是帮助您入门或改进异常处理的9个最重要的内容。

1.清理Finally块中的资源或使用Try-With-Resource语句

经常发生在try块中使用资源，比如InputStream，之后需要关闭它。这些情况下的一个常见错误是在try块结束时关闭资源。

问题是只要没有抛出异常，这种方法似乎完全正常。try块中的所有语句都将被执行，资源将被关闭。

但是你添加了try块是有原因的。您调用一个或多个可能引发异常的方法，或者您自己抛出异常。这意味着您可能无法到达try块的末尾。因此，您不会关闭资源。

因此，您应该将所有清理代码放入finally块或使用try-with-resource语句。

使用Finally块

与try块的最后几行相比，finally块始终执行。这可以在成功执行try块之后或在catch块中处理异常之后发生。因此，您可以确保清理所有已打开的资源。

Java 7的资源尝试声明

另一种选择是try-with-resource语句，我在Java异常处理的介绍中对此进行了更详细的解释。

如果资源实现AutoCloseable接口，则可以使用它。这就是大多数Java标准资源所做的事情。当您在try子句中打开资源时，它将在try块执行后自动关闭，或者处理异常。

2.首选特殊例外情况

抛出的异常越具体越好。请记住，不知道您的代码的同事，或者您可能在几个月内需要调用您的方法并处理异常。

因此，请务必尽可能多地提供信息。这使您的API更容易理解。因此，您的方法的调用者将能够更好地处理异常或通过额外的检查来避免它。

因此，总是尝试找到最适合您的异常事件的类，例如抛出NumberFormatException而不是IllegalArgumentException。并避免抛出非特定的异常。

3.记录您指定的例外情况

只要在方法签名中指定了异常，就应该在Javadoc中记录它。这与以前的最佳实践具有相同的目标：为调用者提供尽可能多的信息，以便他可以避免或处理异常。

因此，请确保向Javadoc 添加@throws声明并描述可能导致异常的情况。

4.使用描述性消息抛出异常

这种最佳实践背后的想法类似于前两种实践。但是这次，您不向调用方提供有关方法的信息。每个必须了解在日志文件或监视工具中报告异常时发生的事情的人都会读取该异常的消息。

因此，它应尽可能准确地描述问题，并提供最相关的信息来理解异常事件。

别误会我的意思; 你不应该写一段文字。但你应该用1-2个短句

来解释异常的原因。这有助于您的运营团队了解问题的严重性，还可以让您更轻松地分析任何服务事件。

如果抛出一个特定的异常，它的类名很可能已经描述了那种错误。因此，您无需提供大量其他信息。一个很好的例子是NumberFormatException。当您以错误的格式提供String时，它会被类java.lang.Long的构造函数抛出。

NumberFormatException类的名称已经告诉您问题的类型。它的消息只需要提供导致问题的输入字符串。如果异常类的名称不具有表现力，则需要在消息中提供所需的信息。

5.首先捕获最具体的异常

大多数IDE都可以帮助您实现这一最佳实践。当您尝试首先捕获不太具体的异常时，它们会报告无法访问的代码块。

问题是只有匹配异常的第一个catch块才会被执行。因此，如果首先捕获IllegalArgumentException，则永远不会到达应该处理更具体的NumberFormatException的catch块，因为它是IllegalArgumentException的子类。

始终首先捕获最具体的异常类，并将不太具体的catch块添加到列表的末尾。

您可以在以下代码段中看到此类try-catch语句的示例。第一catch块处理所有NumberFormatException的 S和第二个所有抛出：IllegalArgumentException S的不是NumberFormatException异常。

6.不要抓住Throwable

Throwable是所有异常和错误的超类。你可以在catch子句中使用它，但你永远不应该这样做！

如果在catch子句中使用Throwable，它不仅会捕获所有异常; 它还会捕获所有错误。JVM抛出错误以指示应用程序无意处理的严重问题。典型的例子是OutOfMemoryError或StackOverflowError。两者都是由应用程序无法控制的情况引起的，无法处理。

所以，最好不要抓住Throwable，除非你完全确定你处于一个特殊情况，你可以或者需要处理错误。

7.不要忽视例外

您是否曾经分析过只有用例的第一部分被执行的错误报告？

这通常是由一个被忽略的异常引起的。开发人员可能非常确定它永远不会被抛出并添加了一个不处理或记录它的catch块。当你发现这个区块时，你很可能甚至会发现一个着名的“这将永远不会发生”的评论。

好吧，你可能正在分析一个不可能发生的问题。

所以，请永远不要忽视异常。您不知道代码将来会如何变化。有人可能会删除阻止异常事件的验证而不会认识到这会产生问题。或者抛出异常的代码会被更改，现在抛出同一个类的多个异常，并且调用代码不会阻止所有这些异常。

你至少应该写一条日志消息，告诉大家不可想象的事情刚刚发生，而且有人需要检查它。

8.不要记录并扔掉

这可能是此列表中最常被忽略的最佳做法。您可以找到许多代码片段，甚至可以找到异常被捕获，记录和重新抛出的库。

在发生异常时记录异常可能会很直观，然后重新抛出它以便调用者可以适当地处理它。但它会为同一个异常写出多条错误消息。

其他消息也不会添加任何信息。如最佳实践＃4中所述，异常消息应描述异常事件。堆栈跟踪告诉您抛出异常的类，方法和行。

如果需要添加其他信息，则应捕获异常并将其包装在自定义异常中。但请务必遵循最佳做法

因此，如果您想要处理它，只捕获异常。否则，在方法签名中指定它并让调用者处理它。

9.在没有消费的情况下包装例外

有时候捕获标准异常并将其包装成自定义异常会更好。此类异常的典型示例是应用程序或框架特定的业务异常。这允许您添加其他信息，还可以为异常类实现特殊处理。

执行此操作时，请确保将原始异常设置为原因。该异常类提供了接受一个特定的构造方法的Throwable作为参数。否则，您将丢失原始异常的堆栈跟踪和消息，这将导致难以分析导致异常的异常事件。

摘要

正如您所看到的，当您抛出或捕获异常时，您应该考虑许多不同的事情。其中大多数都旨在提高代码的可读性或API的可用性。

例外通常是错误处理机制和通信媒介同时。因此，您应该确保讨论要与同事一起应用的Java异常处理最佳实践和规则，以便每个人都能理解一般概念并以相同的方式使用它们。

将Retrace APM与代码分析一起使用时，您可以直接从Java 收集异常，而无需更改任何代码！

原文链接：

http://www.flammulina.com/2018/10/20/%E5%A4%84%E7%90%86java%E5%BC%82%E5%B8%B8%E7%9A%849%E4%B8%AA%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5/返回搜狐，查看更多

责任编辑：