c# - 对何时抛出异常感到困惑

Question

我正在开发一个旨在与外部设备通信(通过 RS232 串行通信)的库。我在考虑错误处理策略，异常似乎是报告错误的正确和行业标准方式。

所以我阅读了一些关于异常的指南。 One非常清楚地表明我不应该担心性能下降:

Do not use error codes because of concerns that exceptions might affect performance negatively.

Other告诉我在正常情况下不要抛出异常:

Do not use exceptions for normal or expected errors, or for normal flow of control.

我无法在正常/预期情况和其他情况之间划清界限。例如在我的库中，操作可能会失败，因为:

1. 设备没有响应。 (未连接电缆，设备未打开，波特率错误)
2. 操作请求被设备拒绝，因为它无法验证请求。
3. 中间通讯失败。 (有人被电缆绊倒，设备突然断电)。

我可以认为以上所有问题都是预期的问题，因为它们在实践中经常发生(事实上，许多营销白痴调用我解决我软件中的 ^问题^ 只是发现他们没有将电缆连接到他们的笔记本电脑)。所以可能不应该抛出异常，否则应用程序程序员将不得不在很多地方捕获它们(我相信很多捕获 block 也不好)。

另一方面，我也倾向于认为这些都是我需要以某种方式向应用程序程序员报告的错误，而异常似乎是这样做的方式。如果我不使用异常，我将需要使用一些错误代码或错误枚举来报告这些问题。 (丑陋，我知道)。

您认为我应该采用哪种方法？

Answer 1

您正在开发一个库，这是一个将被其他应用程序使用的组件。

因此，在您提到的预期情况下，我肯定会使用异常来告知调用应用程序出现问题。您应该为这些场景中的每一个定义一个自定义异常，然后清楚地记录它们可能发生的时间。

然后，这允许应用程序客户端代码决定如何最好地进行。只有客户端应用程序才能做出此决定，明确记录的异常对此有很大帮助。

自定义异常的最大好处是您可以提供与问题/异常相关的多个有意义/有用的数据。此数据也很好地封装在一个对象中。将其与错误代码和返回值进行比较。

性能可能是一个问题，但只有当异常在紧密循环或其他一些高事件情况下抛出时才会出现。为避免这种情况，您还可以应用 .NET Framework 使用的模式，即提供 Try....() 方法(例如 TryParse())，该方法返回指示操作成功或失败的 bool 值。

无论哪种方式，我最初都会使用自定义异常，然后进行性能测试以实际查看库的某些部分是否需要优化。