为什么Catch(Exception)几乎总是一个坏主意？

Question

为什么catch(Exception)几乎总是一个坏主意？

Answer 1

因为当你捕获异常时,你应该正确处理它.而且您不能指望在代码中处理所有类型的异常.此外,当您捕获所有异常时,您可能会遇到一个异常,该异常无法处理并阻止堆栈中的代码正确处理它.

一般原则是捕捉最具体的类型.

Answer 2

简短的故事:它被称为bug掩蔽.如果你有一段代码不能正常工作并抛出异常(或者你将错误的输入传递给那段代码)而你只是通过捕获所有可能的异常而使你的眼睛失明,那么你实际上永远不会发现错误并修复它.

Answer 3

如果能够正确处理异常,您应该只捕获异常.由于你不能正确处理所有可能的异常,你不应该抓住它们:-)

Answer 4

我发现 的两种可接受的用途catch(Exception)：

• 在应用程序的顶层（就在返回给用户之前）。这样你就可以提供足够的信息。
• 使用它来将低级异常屏蔽为业务异常。

第一种情况是不言自明的，但让我来阐述第二种情况：

正在做：

try {
    // xxxx
} catch(Exception e) {
    logger.error("Error XXX",e)
}

是像 @dimitarvp 所说的错误屏蔽。

但下面的情况有所不同：

try {
    // xxxx
} catch(Exception e) {
    throw new BusinessException("Error doing operation XXX",e)
}

这样您就不会忽视错误并将它们隐藏在地毯下。您正在向更高的应用程序层提供高级异常和更具解释性的消息。

在正确的层管理异常也始​​终很重要。如果将低级别的异常升级到高业务层，高层实际上不可能很好地管理它。

在这种情况下，我更喜欢用业务异常来掩盖低级异常，该业务异常可以提供更好的上下文和消息，并且还具有原始异常，以便能够深入了解详细信息。

即便如此，如果你能捕获更具体的异常并为它们提供更好的处理，你就必须这样做。

如果在代码块中您可以得到 anSQLException和 a，NetworkException则您必须捕获它们并为每个代码提供足够的消息和处理。但如果在 try/catch 块的末尾你有一个Exception将其映射到 a 的方法，BusinessException那对我来说就可以了。

事实上，我发现当更高的服务层仅抛出业务异常（内部有详细信息）时就足够了。

Answer 5

因为你真的不知道为什么会发生异常,并且有几个例外需要非常特殊的汽车才能正确处理(如果可能的话),例如OutOfMemoryException和类似的低级系统异常.

因此,您应该只捕获异常:

• 你知道如何处理它(例如FileNotFoundException等)
• 之后你会重新提升它们(例如进行失败后清理)
• 何时需要将异常传输到另一个线程

Answer 6

这取决于你需要什么。如果您需要以不同的方式处理不同类型的异常，那么您应该使用多个 catch 块并尽可能多地捕获特定的异常。

但有时您可能需要以相同的方式处理所有异常。在这种情况下 catch(Exception) 可能没问题。例如：

    try
    {
        DoSomething();
    }
    catch (Exception e)
    {
        LogError(e);
        ShowErrorMessage(e); // Show "unexpected error ocurred" error message for user.
    }