多次尝试赶上还是一个？
通常情况下，我会这样做：
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
更新：
我最初问这个问题W /参考C＃，但正如A.利维评论说，它可以适用于任何exception处理语言，所以我做了标签反映。
这取决于。 如果要为特定错误提供特殊处理，请使用多个catch块：
try { // code that throws an exception // this line won't execute } catch (StackOverflowException ex) { // special handling for StackOverflowException } catch (Exception ex) { // all others }
但是，如果意图处理exception并继续执行，请将代码置于单独的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 }
对于特定的exception，只要使用多个catch块（除非块中只有大量的代码，只有几行可能会引发exception。在这种情况下，我会采用第二种方法）。
如果我可以select第二个，我可能会把它分成两个函数。
你正在考虑这个错误的方式。 你需要做什么在你的catch块？ 如果要通过运行相同的代码从任何可能的exception中恢复 ，不pipe哪个操作抛出exception，然后使用一个catch块。 如果您需要根据抛出的操作进行不同的清理操作，请使用多个catch块。
另外，如果你可以使用try / finally或RAII模式而不是try / catch，那么你应该这样做。
第二种方法在我看来更好，因为它可以让你更准确地捕捉错误。
如果您的应用程序存在某种问题，并且崩溃，但是由于您陷入了一个大的通用执行，那么您可以正确处理它的机会就会降低。 你应该在里面试试看，如果你正在阅读一个文件或者用户input。 这样你可以更好地处理这种模仿
我更喜欢第二种方法 – 它使debugging更容易，error handling更准确，也很好地馈送到你的unit testing。
我会去第二个选项，但是每当我看到这个代码模式，我的第一感觉就是想把它分解成多个函数/方法。 显然是否这样做取决于代码在做什么;）
这取决于您的代码中发生错误的types的性质。
-
如果处理这些错误，你将要做的是同样的单一的尝试…赶上这组代码。 否则它将是太乏味。
-
如果错误需要不同的处理，分开它，因为你必须。
对于所有情况，不要使用单一方法。 编程的大部分时间是上下文的具体:)
您需要达到“GOOD / COMPLEX”和“BAD / SIMPLE”的平衡。 你代码越多，你就会陷入这种困境:)
快乐编程！
第二种方法。 保持可能抛出一个exception的代码与其他代码分离 – 保持该部分更小，更容易pipe理，而不是包装所有代码，甚至不会抛出exception。
第二种方式，但理想地使用守卫 – 尝试/捕获是昂贵的
