Java 异常处理的 9 个最佳实践 已翻译 100%

oschina 投递于 01/30 14:36 (共 13 段, 翻译完成于 02-02)
阅读 6004
收藏 106
2
加载中

在 Java 中,异常处理是个很麻烦的事情。初学者觉得它很难理解,甚至是经验丰富的开发者也要花费很长时间决定异常是要处理掉和抛出。

所以很多开发团队约定一些原则处理异常。如果你是一个团队的新成员,你可能会很惊讶,因为他们约定的规则可能和你以前使用的规则不一样。

不过,有很多最佳实践的规则,被大部分团队接受。这里有 9 大重要的约定,帮助你学习或者改进异常处理。

lee
lee
翻译于 01/30 16:44
2

1、在 Finally 清理资源或者使用 Try-With-Resource 特性

大部分情况下,在 try 代码块中使用资源后需要关闭资源,例如 InputStream 。在这些情况下,一种常见的失误就是在 try 代码块的最后关闭资源。

问题就是,只有没有异常抛出的时候,这段代码才可以正常工作。try 代码块内代码会正常执行,并且资源可以正常关闭。但是,使用 try 代码块是有原因的,一般调用一个或多个可能抛出异常的方法,而且,你自己也可能会抛出一个异常,这意味着代码可能不会执行到 try 代码块的最后部分。结果就是,你并没有关闭资源。

所以,你应该把清理工作的代码放到 finally 里去,或者使用 try-with-resource 特性。

lee
lee
翻译于 01/30 16:58
2

使用 Finally 代码块

与前面几行 try 代码块不同,finally 代码块总是会被执行。不管 try 代码块成功执行之后还是你在 catch 代码块中处理完异常后都会执行。因此,你可以确保你清理了所有打开的资源。

我是菜鸟我骄傲
我是菜鸟我骄傲
翻译于 01/31 09:31
1

Java 7 的 Try-With-Resource 语法

另一个可选的方案是 try-with-resource 语法,我在介绍 Java 的异常处理里更详细的介绍了它。

如果你的资源实现了 AutoCloseable 接口,你可以使用这个语法。大多数的 Java 标准资源都继承了这个接口。当你在 try 子句中打开资源,资源会在 try 代码块执行后或异常处理后自动关闭。

我是菜鸟我骄傲
我是菜鸟我骄傲
翻译于 01/31 09:41
1

2、优先明确异常

你抛出的异常越明确越好,永远记住,你的同事或者几个月之后的你,将会调用你的方法并且处理异常。

因此需要保证提供给他们尽可能多的信息。这样你的 API 更容易被理解。你的方法的调用者能够更好的处理异常并且避免额外的检查

因此,总是尝试寻找最适合你的异常事件的类,例如,抛出一个 NumberFormatException 来替换一个 IllegalArgumentException 。避免抛出一个不明确的异常。

madbooker
madbooker
翻译于 01/31 16:36
1

3、记录指定的异常

每当你在方法签名中指定异常,你也应该在 Javadoc 中记录它。 这与上一个最佳实践具有相同的目标:尽可能多地向调用者提供信息,以便避免或处理异常。

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

凉凉_
凉凉_
翻译于 01/30 17:03
0

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

这个最佳实践背后的想法与前两个类似。但这一次,你不会将信息提供给方法的调用者。每个必须了解在日志文件或监视工具中报告异常情况时发生了什么情况的人都可以读取异常消息。

因此,应该尽可能精确地描述问题,并提供最相关的信息来了解异常事件。

不要误会我的意思,你不用去写一段文字。但你也应该在1-2个短句中解释异常的原因。这有助于你的运营团队了解问题的严重性,并且还可以让你更轻松地分析任何服务突发事件。

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


NumberFormatException 类的名称已经告诉你这种问题。它的消息表示只需要提供导致问题的输入字符串。如果异常类的名称不具有表达性,则需要在消息中提供所需的信息。

17:17:26,386 ERROR TestExceptionHandling:52 - java.lang.NumberFormatException: For input string: "xyz"
凉凉_
凉凉_
翻译于 01/30 17:12
1

5、优先捕获最具体的异常

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

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

总是优先捕获最具体的异常类,并将不太具体的 catch 块添加到列表的末尾。

你可以在下面的代码片断中看到这样一个 try-catch 语句的例子。 第一个 catch 块处理所有 NumberFormatException 异常,第二个处理所有非 NumberFormatException 异常的  IllegalArgumentException 异常。

凉凉_
凉凉_
翻译于 01/30 17:15
0

6、不要捕获 Throwable 类

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

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

所以,最好不要捕获 Throwable ,除非你确定自己处于一种特殊的情况下能够处理错误。

凉凉_
凉凉_
翻译于 01/30 17:20
0

7、不要忽略异常

你曾经有去分析过一个只执行了你用例的第一部分的 bug 报告吗?

这通常是由于一个被忽略的异常造成的。开发者可能会非常肯定,它永远不会被抛出,并添加一个 catch 块,不做处理或不记录它。而当你发现这个块时,你很可能甚至会发现其中有一个“这永远不会发生”的注释。


那么,你可能正在分析一个不可能发生的问题。

所以,请不要忽略任何一个异常。 你不知道代码将来如何改变。有人可能会在没有意识到会造成问题的情况下,删除阻止异常事件的验证。或者是抛出异常的代码被改变,现在抛出同一个类的多个异常,而调用的代码并不能阻止所有异常。

你至少应该写一条日志信息,告诉大家这个不可思议的事发生了,而且有人需要检查它。

凉凉_
凉凉_
翻译于 01/30 17:36
0
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(8)

-TNT-
-TNT-
“再次抛出异常”的问题是打了个日志…而且一般也是wrap一下再抛的
momisabuilder
momisabuilder
赞.
周翔
周翔

引用来自“烨儿”的评论

个人觉得异常不应该被底层"吞掉",而是捕获处理后应该继续抛出异常.否则调用端根本不知道出错了.
异常处理的原则是能处理就处理,否则抛出.底层如果能处理异常,吞掉也是可以的.看情况
JPer
JPer
再次抛出异常可能比如说:我是服务提供方,异常抛出去是让调用者知道触发异常了而不是返回一个null或者其他model,当然同时服务提供方也得记录这个异常,方便我方追查;所以,还得区分不通的业务场景,不能一概而论;
charles_wang
charles_wang

引用来自“小灰灰Blog”的评论

第八条是什么意思,没太明白记录日志后再直接抛出会有什么问题
如果底层进行log一次,然后再抛出后被上层 再打一次日志,就会重复打日志.
小灰灰Blog
小灰灰Blog
第八条是什么意思,没太明白记录日志后再直接抛出会有什么问题
南望山阿飞
南望山阿飞

引用来自“烨儿”的评论

个人觉得异常不应该被底层"吞掉",而是捕获处理后应该继续抛出异常.否则调用端根本不知道出错了.
所以调用端,首先得做验证,至于漏网之鱼才是后端需要处理的
烨儿
烨儿
个人觉得异常不应该被底层"吞掉",而是捕获处理后应该继续抛出异常.否则调用端根本不知道出错了.
返回顶部
顶部