c# - 明智地使用 try / catch

Question

我希望这个话题不会太哲学:)

一般来说，我正在开发一个与外部世界有很多联系的应用程序。您保存和读取文件、连接到数据库、读取通过 TCP 协议传入的数据包、将打印任务发送到打印机、解析用户文本输入等等。从理论上讲，这些操作中的每一个都可能以多种可能的方式出错。

我的问题是我厌倦了为数百条指令编写 try/catch 块。它使代码的长度增加了一倍，阅读起来更糟糕，而不是做一些“真正的”编码，我继续将可能永远不会发生的消息写入日志。

但是还有其他选择吗？

你的方法是什么？制作所有这些 try/catch 块？或者只是忽略这些可能的错误并仅在用户报告它们之后处理实际错误？

我们是否应该永远不允许应用程序崩溃，我们应该预测用户的任何愚蠢行为，还是用户不做愚蠢行为的问题？

将大块代码放入 try/catch 还是将单个指令放入其中更好？

我将不胜感激任何建议或意见。

Answer 1

如果您的代码的一部分可能会中断，则不应使用异常。

例外是特殊情况！

这篇 MSDN 文章提出了一些明智的警告，即 Tester-Doer 模式和 Try-Parse 模式。

Answer 2

你应该try围绕那些实际上可能失败的部分来写。这些通常是网络操作本身，而不是它们周围的所有其他代码。如果您try-protect 过多的代码，您可能会捕获不是网络错误的异常，但您的代码可能会误认为它们。

如果您确实必须try-protect 许多行（可能是因为您正在使用 a 进行细粒度读取BinaryReader），您可以将 的内容try放入单独的方法中。这摆脱了缩进并隐藏了很多复杂性。Resharper 可以很容易地提取方法。

无论如何，您都需要一个顶级异常处理程序来记录通常是错误的意外错误。这些也确实发生了。

仅在您可以合理处理错误或记录该特定错误并重新抛出时才捕获。我发现在大多数情况下，我只需要很少的catch处理程序，因为大多数错误只能通过中止进程来处理。