我希望这个主题不会过于哲学化。）
一般来说，我正在开发一个与外部世界有很多联系的应用程序。 您可以保存和读取文件，连接到数据库，读取通过TCP协议传输的数据包，将打印任务发送到打印机，解析用户文本输入等。理论上，这些操作中的每一个都可能以多种可能的方式出错。
我的问题是我已经厌倦了为数百条指令编写try / catch块。它使代码长两倍，读取更糟糕，而不是做一些“真正的”编码，我继续将消息写入日志，这可能永远不会发生。
但还有其他选择吗？
你的方法是什么？制作所有这些try / catch块？或者只是忽略这些可能的错误并仅在用户报告后处理ACTUAL错误？
我们是否应该永远不允许应用程序崩溃，我们是否应该预测用户的任何愚蠢行为，或者用户是否有问题不进行愚蠢的操作？
最好将大块代码放入try / catch或将单个指令放入其中吗？
我很感激任何建议或意见。
答案 0 :(得分：5)
答案 1 :(得分：1)
您应该围绕那些实际可能失败的部分编写try。这些通常是网络操作本身，而不是围绕它们的所有其他代码。如果您try - 保护过多的代码，则可能会发现不网络错误的异常，但您的代码可能会误认为是这样。
如果您必须try - 保护多行（可能是因为您使用BinaryReader进行细粒度读取），您可以将try的内容放入单独的内容中方法。这摆脱了缩进并隐藏了很多复杂性。 Resharper可以很容易地提取方法。
无论如何，您需要一个顶级异常处理程序来记录通常是错误的意外错误。这些确实发生了。
只有在合理处理错误时才会捕获，或者您记录该特定错误并重新抛出。我发现在大多数情况下我需要很少catch个处理程序，因为除了通过中止进程，大多数错误都无法处理。