Question

大多数静态代码分析工具建议不要捕获一般（特别是未经检查的）异常，例如RuntimeExceptions和Errors。

除非此顶级屏障在最高级别可能是合理的，否则通常不会处于较低级别。不幸的是，在重写/修复现有代码时，这很难实现，因为可能的错误和RuntimeExceptions的潜在可能性可能过高。此外，挖掘较低的代码级别来获取一些合理的Exceptions概念，而不是通用的catch，这是一个非常耗时且复杂的任务。

您是否知道将这些通用（未经检查）的异常解析为更具体的异常的任何工具或最佳做法？

说我们有类似的东西：

try
{
    somethingReallyComplex();
}
catch (RuntimeException | Error ex)
{
    Logger.error(this, ex.getClass().getName() + " while doing something really complex", ex)
}

try块可以包含一个非常复杂的代码问题，其中包含各种不同的RuntimeExceptions和错误，有意义可以捕获。但是，如何最有效地分析此代码以将RuntimeException解析为NullPointerException，ArrayIndexOutOfBoundException ......无论什么都合理？

是否有任何工具可以分析此类代码并提供有关大多数常见RuntimeExceptions的建议等等？

你如何开始解决这个问题？

主观或客观“门槛”在哪里说： “不，我只是把它作为RuntimeException并添加一个抑制注释？”

Answer 1

关于捕获常规异常的最重要的事情是你抓住它们，而不是是否。如果你在一个中心位置，一个所谓的异常障碍，它在调用堆栈中处于高位，那么这正是你应该做的。如果你在代码中间做了一些或多或少的任意点，这将是一个不好的做法。

Answer 2

举证责任不应该在您身上，而是在您希望更改代码的工具上。任何合理的静态分析工具都会给出特定警告背后的基本原理，使您能够评估在您的特定情况下忽略该警告的影响。（大多数警告都存在，因为他们标记的代码经常有问题，而不是因为它总是。）

有一些情况下，捕获异常是正确的做法，因为恢复逻辑非常普遍，不需要区分异常，例如，如果你实现了类似的东西：“如果出现问题，请重试两次。如果仍然无效，请记录异常，通知用户，然后继续“。这实际上取决于您的异常处理程序的功能。

Answer 3

虽然不建议我通常会捕获一般的异常，毕竟我要做的唯一事情是写入日志并继续。

如果你必须根据爆炸的内容预先形成不同的清理任务，那么在尝试之后获得6个或任何捕获块可能是有用的。

Answer 4

在我看来，代码的每个部分都应该捕获它知道如何处理的异常，并且它抛出的所有已检查异常都应具有与此代码相关的含义。一个基本机制是将处理的所有异常包装到此方法抛出的已检查异常类型中。此规则（huhu）的例外是RuntimeExceptions，主要是您不应该尝试捕获的错误（请参阅Error javadoc）。

因此，对于我来说，try {}块中的每个方法都应该抛出带有与方法相关的语义的已检查异常。并且递归地你在所有这些方法上做同样的事情，但我看不到任何足够聪明的工具来为你做这件事。

“不要抓住通用的例外！”但是如何揭开它们呢？

4 个答案: