error-checking - 错误检查矫枉过正？

Question

你做什么错误检查？实际上需要什么错误检查？我们真的需要检查文件是否保存成功吗？如果从第一天开始就经过测试并且可以正常工作，它不应该总是有效吗？

我发现自己对每一件小事都进行了错误检查，而且大多数情况下感觉有点矫枉过正。诸如检查文件是否已成功写入文件系统，检查数据库语句是否失败............这些不应该是工作还是不工作？

你做了多少错误检查？您是否因为相信它会正常工作而忽略了错误检查的元素？

我确定我记得在某处读过类似“不要测试永远不会真正发生的事情”之类的东西……但不记得出处。

那么是否应该检查所有可能失败的东西是否失败？还是我们应该相信那些更简单的操作？例如，如果我们可以打开一个文件，我们是否应该检查读取每一行是否失败？也许这取决于应用程序中的上下文或应用程序本身。

听听别人怎么做会很有趣。

更新：作为一个简单的例子。我在画廊中保存了一个代表图像的对象。然后我将图像保存到光盘。如果文件保存失败，即使对象认为有图像，我也必须显示图像。我可以检查将图像保存到磁盘是否失败，然后删除对象，或者将图像保存在事务（工作单元）中 - 但是在使用使用表锁定的数据库引擎时，这可能会变得昂贵。

谢谢，

詹姆士。

Answer 1

如果您用完了可用空间并尝试写入文件并且不检查错误，您的应用程序将无声无息地下降或出现愚蠢的消息。我讨厌在其他应用程序中看到这个。

Answer 2

我没有解决整个问题，只是这一部分：

那么是否应该检查所有可能失败的东西是否失败？还是我们应该相信那些更简单的操作？

在我看来，当 NEXT 步骤很重要时，错误检查是最重要的。如果无法打开文件将导致错误消息永久丢失，那么这是一个问题。如果应用程序会简单地死掉并给用户一个错误，那么我会认为这是一种不同的问题。但是，默默地死去，或者默默地挂起，是一个你应该尽最大努力编写代码的问题。因此，某事是否是“简单操作”与我无关；这取决于接下来会发生什么，或者如果失败会是什么结果。

Answer 3

我通常遵循这些规则。

1. 过度验证用户输入。
2. 验证公共 API。
3. 使用从生产代码中编译出来的断言用于其他所有内容。

Answer 4

关于你的例子......

我在画廊中保存了一个代表图像的对象。然后我将图像保存到光盘。如果文件保存失败，即使对象认为有图像，我也会显示 [no] 图像。我可以检查将图像保存到磁盘是否失败，然后删除该对象，或者将图像保存在事务（工作单元）中 - 但是当使用使用表锁定的数据库引擎时，这可能会变得昂贵。

在这种情况下，我建议先将图像保存到磁盘，然后再保存对象。这样，如果图像无法保存，您就不必尝试回滚图库。通常，依赖项应该首先写入磁盘（或放入数据库）。

至于错误检查...检查有意义的错误。如果fopen()给您一个文件 ID 并且您没有收到错误，那么您通常不需要检查fclose()该文件 ID 是否返回“无效文件 ID”。但是，如果文件打开和关闭是不相交的任务，那么检查该错误可能是个好主意。

Answer 5

这可能不是您正在寻找的答案，但在您尝试做的事情的完整背景下查看时，只有一个“正确”的答案。

如果您正在编写一个供内部使用的原型并且如果您遇到奇怪的错误，那没关系，那么您通过添加额外的检查来浪费时间和公司资金。

另一方面，如果您正在编写用于空中交通管制的生产软件，那么处理每个可能出现的错误的额外时间可能会花得很好。

我认为这是一种权衡 - 编写错误代码所花费的额外时间与在错误发生时处理该错误所带来的好处。宗教地处理每一个错误并不是最佳的 IMO。