多个try-catch还是一个？答案

【问题标题】：Multiple try-catch or one?多个try-catch还是一个？
【发布时间】：2010-07-13 17:46:29
【问题描述】：

通常，我会这样做：

try
{
    code

    code that might throw an anticipated exception you want to handle

    code

    code that might throw an anticipated exception you want to handle

    code
}
catch 
{

}

这样做有什么好处吗？

code

try
{
    code that might throw an anticipated exception you want to handle
}
catch
{
}

code

try
{
    code that might throw an anticipated exception you want to handle
}
catch
{
}

code

更新：

我最初问这个问题时参考了 C#，但正如 A. Levy 评论的那样，它可以适用于任何异常处理语言，所以我让标签反映了这一点。

【问题讨论】：

您希望处理在第一个错误发生时立即停止（第一个示例），还是即使部分处理失败（另一个）也可以继续？
@DLP - 我希望它停止处理 - 我看到有人在你之后提到它。这是一个很好的观点。
虽然你用 C# 和 .net 标记了它，但我认为它真的与语言无关。这个问题适用于除 Java、C++、JavaScript、OCaml、F#、Python、Clojure 等例外的任何语言。它也适用于 Common Lisp 和各种其他 Lisp 中的条件/重启系统。所以我要求你让这种语言不可知......不过你的电话。

标签： exception-handling

【解决方案1】：

这取决于。如果您想为特定错误提供特殊处理，请使用多个 catch 块：

try
{ 
    // code that throws an exception
    // this line won't execute
}
catch (StackOverflowException ex)
{
    // special handling for StackOverflowException 
}
catch (Exception ex)
{
   // all others
}

但是，如果目的是处理异常并继续执行，请将代码放在单独的 try-catch 块中：

try
{ 
    // code that throws an exception

}
catch (Exception ex)
{
   // handle
}

try
{ 
    // this code will execute unless the previous catch block 
    // throws an exception (re-throw or new exception) 
}
catch (Exception ex)
{
   // handle
}

【讨论】：

+1 ，在第一个示例中突出显示，确保 General 异常处理程序位于声明中的最后一个，以便您首先处理特定的，然后以通用方式处理您无法控制的任何其他内容。
如此处所述：developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…，条件捕获的使用是非标准的，并且不在标准轨道上。不要在面向 Web 的生产站点上使用它：它不适用于每个用户。实现之间也可能存在很大的不兼容性，并且未来的行为可能会发生变化。

【解决方案2】：

如果我可以选择第二个，我可能会将其分成两个函数。

【讨论】：

+1：我完全同意，尽管我可能会写成“如果我可以选择第二个，我会..”，因为我认为这是任何时候都应该做的事情可能...

【解决方案3】：

有时我们想向用户显示特定的错误。

try{
   try{
      ... send message
   }
   catch(exception e){
    ...log error
    ...rethrow  send related error/show custom error
   }
   try{
       ...try to receive response
   }
   catch(exception e){
       ...show receive related error
   }
   //finally close the connection
   }finally{
        ...close connection
   }

【讨论】：

【解决方案4】：

你想错了。你需要在你的 catch 块中做什么？如果您希望通过运行相同的代码从任何可能的异常中恢复，无论哪个操作引发了异常，那么请使用一个 catch 块。如果您需要根据抛出的操作执行不同的清理操作，请使用多个 catch 块。

另外，如果您可以使用 try/finally 或 RAII 模式而不是 try/catch，那么您应该这样做。

【讨论】：

【解决方案5】：

也不行，只对特定异常使用多个 catch 块（除非块中只有大量代码，并且只有几行可能会引发异常。在这种情况下，我会使用第二种方法）。

【讨论】：

【解决方案6】：

我认为第二种方法更好，因为它可以让您更准确地捕获错误。

同样将整个代码包装在一个大的 try/catch 块中也是不好的，如果您的应用程序有某种问题并且它崩溃了，但是由于您捕获了一个大的通用执行，那么您实际上可以正确处理它的机会就更低了。你应该在 try catch 中有特殊的部分，比如你读取文件或接受用户输入。这样您就可以更好地处理该异常

【讨论】：

【解决方案7】：

第二种方法。将可能引发异常的代码与其他代码分开 - 使该部分更小且更易于管理，而不是包装所有代码，即使是不会引发异常的代码。

【讨论】：

【解决方案8】：

第二种方式，但最好使用代码保护 - 如果捕获异常，try/catch 可能会很昂贵。

【讨论】：

C# 中的 Try/catch 成本真的不是很高，除非你真的捕捉到了一些东西......
PS：我意识到这个答案已有 7 年的历史，但想把它放在 2017 年的背景下...... Try/Catch 的性能影响大大超过引用，想象的性能提升绝不是一个好的理由更好、更可靠的代码，特别是当你意识到当 .NET 出现时，你能买到的最好的计算机是 Pentium 4 w/1-2GB 内存，而今天我们有 4 个内核，超线程，速度超过 8 倍，而且8-16GB RAM 是常态。最重要的是，即使在相同的硬件上，.NET 编译的代码也比 15 年前更快。调用 Try/Catch 慢是一个神话，它需要停止。

【解决方案9】：

我更喜欢第二种方法——它使调试更容易，错误处理更准确，也很好地融入你的单元测试。

【讨论】：

【解决方案10】：

我会选择第二个选项，但每当我看到此代码模式时，我的第一感觉就是考虑将其拆分为多个函数/方法。显然是否这样做取决于代码在做什么;)

【讨论】：

【解决方案11】：

这取决于代码中发生的错误类型的性质。

如果您要处理的这些错误与该组代码的单次尝试 ... 捕获相同。否则就太乏味了。
如果错误需要不同的处理，请将其分开，因为你必须这样做。

不要对所有情况都采用一种方法。编程大部分时间是特定于上下文的:)

您需要在“好/复杂”和“坏/简单”之间取得平衡。你编码的越多，你就会越少陷入这种困境:)

编程愉快！

【讨论】：

一般来说，用大写锁定写一个完整的句子是一种糟糕的形式。但最后，这是特定于上下文的