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