.net 嵌套的 Try/Catch 块是个坏主意吗？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/4799758/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Are nested Try/Catch blocks a bad idea?
提问by Goro
Let's say we have a structure like so:
假设我们有一个这样的结构：
Try
' Outer try code, that can fail with more generic conditions,
' that I know less about and might not be able to handle
Try
' Inner try code, that can fail with more specific conditions,
' that I probably know more about, and are likely to handle appropriately
Catch innerEx as Exception
' Handle the inner exception
End Try
Catch outerEx as Exception
' Handle outer exception
End Try
I have seen some opinions that nesting Tryblocks like this is discouraged, but I could not find any specific reasons.
我看到一些意见认为Try不鼓励这样的嵌套块，但我找不到任何具体原因。
Is this bad code? If so, why?
这是坏代码吗？如果是这样，为什么？
回答by Basic
There are certain circumstances where they're a good idea, e.g. one try/catch for the whole method and another inside a loop as you want to handle the exception and continue processing the rest of a collection.
在某些情况下，它们是一个好主意，例如，一个 try/catch 用于整个方法，另一个在循环中，因为您想要处理异常并继续处理集合的其余部分。
Really the only reason to do it is if you want to skip the bit that errored and carry on, instead of unwinding the stack and losing context. Opening multiple files in an editor is one example.
真正这样做的唯一原因是，如果您想跳过出错的位并继续，而不是展开堆栈并丢失上下文。在编辑器中打开多个文件就是一个例子。
That said, exceptions should (as the name implies) be exceptional. A program should handle them but try to avoid them as part of normal execution flow. They're computationally expensive in mostlanguages (Python being one notable exception).
也就是说，异常应该（顾名思义）是异常的。程序应该处理它们，但尽量避免将它们作为正常执行流程的一部分。在大多数语言中，它们的计算成本很高（Python 是一个显着的例外）。
One other technique which can be useful is catching specific exception types...
另一种有用的技术是捕获特定的异常类型......
Try
'Some code to read from a file
Catch ex as IOException
'Handle file access issues (possibly silently depending on usage)
Catch ex as Exception
' Handle all other exceptions.
' If you've got a handler further up, just omit this Catch and let the
' exception propagate
Throw
End Try
We also use nested try/catches in our error handling routines...
我们还在错误处理例程中使用嵌套的 try/catchs...
Try
Dim Message = String.Format("...", )
Try
'Log to database
Catch ex As Exception
'Do nothing
End Try
Try
'Log to file
Catch ex As Exception
'Do nothing
End Try
Catch ex As Exception
'Give up and go home
End Try
回答by Dan Tao
I actually don't think there's anything inherently wrong about nested Try/Catchblocks, except that they can be difficult to navigate and are likely a sign that you could do some refactoring (the inner Try/Catchinto its own method, for example).
我实际上并不认为嵌套Try/Catch块有任何本质上的错误，除了它们可能难以导航并且可能表明您可以进行一些重构（例如，将内部Try/重构Catch为它自己的方法）。
But I do want to address this comment:
但我确实想解决这个评论：
' Outer try code, that can fail with more generic conditions,
' that I know less about and might not be able to handle
If you don't know how to handle exceptions in a particular situation, trust me: don'tcatch them. Better to let your app crash (I mean, you know, logit; just don't swallow it) than to catch something you don't know how to recover from and then let your app continue merrily on its way in a corrupted state. Behavior will be unpredictable at best from that point on.
如果您不知道如何在特定情况下处理异常，请相信我：不要捕捉它们。最好让你的应用程序崩溃（我的意思是，你知道，记录它；只是不要吞下它），而不是抓住一些你不知道如何恢复的东西，然后让你的应用程序在损坏的状态下继续快乐地前进. 从那时起，行为充其量是不可预测的。
