捕获通用的非致命异常[关闭]

Question

传统观点认为我们应该只捕获我们期望的特定异常类型：

try
{           
    int.Parse(str); //I am aware of TryParse(), this is just for the sake of example
}
catch (FormatException ex)
{
    Console.WriteLine (ex);
}
catch (OverflowException ex)
{
    Console.WriteLine (ex);
}

但是，有时我们并不真正关心发生了哪个异常（只要它不是致命的），可能是因为我们只是想让用户知道发生了错误。在这些情况下，我们可以这样做：

try
{           
    Foo();
}
catch (Exception ex)
{
    if (IsCriticalException(ex))
    {
        Environment.FailFast("System Error", ex);
    }

    Console.WriteLine ("Error running Foo: {0}", ex);
}   

IsCriticalException 的实现方式与System.ClientUtils.IsCriticalException 类似。出于以下几个原因，我通常赞成这种方法：

1. 有些方法可以抛出许多异常类型，捕获它们可能很麻烦。例如，File.Open 可以抛出九种不同类型的异常。
2. 某些方法可能会引发未记录的异常。这要么是由于缺少文档，要么是由于某些错误。例如，ICommunicationObject.Close 实际上可以抛出 ArgumentException，这是由于一个模糊的错误。有些方法甚至不能静态地知道它们会抛出哪些异常，因为它们会动态加载其他模块/插件。假设他们可以用他们自己已知的异常来包装所有这些“外部”异常，但我相信并不是所有的都这样做。

这种方法的批评者认为方法的异常是其契约的一部分。如果抛出不属于本合约的异常，我们应该假设它的状态是损坏的。我们还将在该方法中发现一个错误（否则我们不会发现一个错误，因为我们已经吞下了意外的异常）。然后我们可以将此错误传递给框架的开发人员，这是一个胜利 - 特别是如果这些开发人员在我们公司，所以我们可以说是“自助”了。

我承认，批评者提出了正确的观点，但我觉得他们有点理想主义。实际上，我认为通用的非致命异常捕获在很多情况下都是有意义的。我说得有道理吗？

相关阅读：

• How to Design Exception Hierarchies
• Vexing exceptions

Answer 1

传统观点认为我们应该只捕获我们期望的特定异常类型

实际上，我认为您应该准确捕获那些您可以处理的异常。捕获异常只是为了重新抛出它们是没有用的，让那些你可以治愈的异常通过也是没有意义的。

在你上面的例子中，我认为有一个包罗万象的块会很好，毕竟不转换该字符串是一个可恢复的错误，无论弹出什么异常（OutOfMemoryException 除外，它无论如何都无法处理，因为任何尝试处理会使用内存）。