问对何时抛出异常感到困惑

EN

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

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

这样，应用程序客户端代码就可以决定如何进行最佳操作。只有客户端应用程序才能做出这一决定，并且明确记录的异常对此有很大帮助。

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

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

无论哪种方式，我最初都会处理自定义异常，然后进行性能测试，以确定库中是否有某些部分可能需要优化。

我将在以下方法中使用例外(受按合同设计的启发)

• 在可能的情况下，提供布尔检查函数，告诉您是否可以安全地应用某个操作。
• 对于给定的操作，将这样的检查函数作为先决条件:如果它有效，则操作可以安全地完成，如果不安全，则抛出异常。

通过这种方式，如果API用户可以使用if -然后-else结构对其关键逻辑进行编码.

如果出现意外情况(例如，由于微妙的时间问题)将抛出一个异常:开发人员可以捕获该异常并处理它。但是请注意:这不一定是在调用方法的地方:它可以在调用堆栈中更高/更早，在处理所有奇怪异常的中心位置。

我在数百万行C程序中完成了错误处理代码的自动化分析。这些是基于要求手写检查和传播错误码的编码标准.结果发现，开发人员不喜欢编写这样的代码，他们忘记了，而且很容易出错。事实上，我们发现了每1000行C代码编码标准的两个偏差(可以说是两个错误)。

• 见M. Bruntink，A. van Deursen和T. Tourwé。D基于习语的异常处理中的故障掩盖.“第28届国际软件工程会议议事录”(ICSE'06)，第242至251页，ACM出版社，2006年。

总之：(1)我使用布尔检查器(2)可以在调用堆栈的较高位置捕获异常；(3)依赖错误代码在实践中是不安全的。

例外情况正是针对这种特殊情况而设计的。我试着这样想--如果你假设你所依赖的一切在大多数情况下都是正常的，而方法X失败了，那么这是一个特殊的情况，因为它通常不会发生，你应该定义异常来捕捉这种情况。

因此，在您的情况下，您假设设备已经启动并运行。因此，在这种情况下，异常情况是设备不接受连接、拒绝连接、不接受您发送的数据或不接收它应该发送的数据等等。如果设备每天经常关闭几次，那么您希望它们被关闭，所以在连接之前使用返回代码或"bool IsDeviceOn()“方法来检查它。

如果您的确实期望在正常情况下发生，比如查询设备的功能，但是您想要的设备是不可用的，那么使用返回代码或bool方法--例如"bool DoesDeviceHaveThisCapability();“不要在没有异常的情况下捕获异常。

另一个例子(用于GUI应用程序)是用户输入。不要对此使用异常，因为您确实期望用户输入错误--我们并不完美。

我已经经历了大量的性能问题，因为使用异常时，它们并不是真正的例外情况。一个例子是当我每天处理2GB数据文件2-3次时。有些行的有效价格为0.00格式。有些人没有。我用FormatException来捕捉那些没有的。

两年后，当我有机会得到一个性能分析器的时候，发现异常的那句话占了分析文件所用时间的80%。我将其改为使用int的TryParse()方法，并获得了巨大的速度增长。

对于您的例子，我可能会使用：

1. 没有来自设备的响应-如果设备应该是24/7，则返回代码，如果正常关闭
2. 未经授权的行动-例外
3. 通讯失败-异常