在什么情况下不应处理异常？

Question

是否有可能制定一个指南来回答：

  

在什么情况下，开发人员不应该处理特定的异常？

为了更好地表达自己，如果一个方法期望参数的一个值为1,2,3,4,5：“Zeta”，并且从业务逻辑的角度来看，如果没有意义那么9就不能用作为参数值，开发人员是否仍应处理可能的参数异常？

Answer 1

如果你从MSDN查看Exceptions documentation，它会说明以下内容：

• 除非你可以处理并离开，否则不要发现异常 申请处于已知状态。如果捕获System.Exception，请重新抛出 它在catch块的末尾使用throw关键字。

因此开发人员应该只捕获他们可以处理的异常。例如，如果用户键入被认为是错误的数字9，则可以向用户显示消息并请求新输入。

如果开发人员在传递9时无法处理ArgumentException，则不应该捕获它。

Answer 2

您应该避免捕获所有非软件异常/错误。例如，OutOfMemory错误就是一个这样的例外。捕获异常通常用于防止应用程序崩溃/退出。这应该只在异常与应用程序的某些错误输入或某些程序错误相关时才会完成。

Answer 3

一般来说，应该避免例外。因此，例如，不要让NullReferenceException发生，而是检查null。请务必检查所有参数是否有效，如果找到无效值，则抛出ArgumentException。

永远不要抓住System.Exception，而是抓住您期望的特定例外。否则，您可以在软件中隐藏严重的错误和问题。

Answer 4

我在这里会有点逆势，因为几乎我见过的每一条建议都会建议（有时是激烈的）你应该只检查你期望的特定例外（你可以处理的例外情况的“白名单”）。

然而，鉴于.NET中缺少检查异常的概念，在许多情况下，您永远无法确定将抛出哪些异常，尤其是在松散耦合的应用程序中。例如，假设我已经使用IoC注入了加密实现，谁可以给我一个详尽的列表，列出当前和未来版本的.NET加密类可能抛出的所有可能的异常？

在这种情况下，有一个你不想处理的例外情况的“黑名单”是合理的，你可以这样做：

try
{
    ...
}
catch(Exception ex)
{
    if (IsInBlackList(ex))
    {
       throw;
    }
    ... code to recover from exception ...
}

.NET Framework本身就有先例，例如，System.Windows.Forms.Application.CommonAppDataPath就是这样做的，使用内部方法ClientUtils.IsSecurityOrCriticalException来定义它的“黑名单”。