错误检查过度杀伤？

Question

你做了什么错误检查？ 实际需要进行哪些错误检查？ 我们真的需要检查文件是否已成功保存？ 如果它经过测试并且从第一天起就可以正常工作，它是否应该始终有效？

我发现自己错误地检查每一件小事，而且大部分时间都觉得有点过分。 比如检查一个文件是否已成功写入文件系统，检查数据库语句是否失败......这些都不应该是有效的吗？

你做了多少错误检查？ 是否存在错误检查的元素，因为您相信它只会起作用？

我敢肯定，我记得曾经读过“不要测试那些永远不会发生的事情”的内容......但是不记得来源了。

所有可能失败的事情都应该检查失败吗？ 或者我们应该相信那些更简单的操作？ 例如，如果我们可以打开文件，我们是否应该检查每行读取是否失败？ 也许它取决于应用程序或应用程序本身的上下文。

听到别人做的事情会很有趣。

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

谢谢，

詹姆士。

Answer 1

如果你的可用空间不足并尝试写文件而不检查错误，你的应用程序将无声地或使用愚蠢的消息。 我讨厌在其他应用程序中看到这个。

Answer 2

我不是在解决整个问题，只是这一部分：

所有可能失败的事情都应该检查失败吗？ 或者我们应该相信那些更简单的操作？

在我看来，当NEXT步骤很重要时，错误检查是最重要的。 如果无法打开文件将允许错误消息永久丢失，那么这是一个问题。 如果应用程序只是死亡并给用户一个错误，那么我会考虑另一种问题。 但是，无声地死亡，或者默默地悬挂，是一个你应该尽力编写代码的问题。 因此，某件事是否属于“简单操作”与我无关; 这取决于接下来发生的事情，或者如果失败将会产生什么结果。

Answer 3

我通常遵循这些规则。

1. 过度验证用户输入。
2. 验证公共API。
3. 使用从生产代码中编译出来的Asserts。

Answer 4

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

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

在这种情况下，我会建议保存图像到磁盘先保存对象之前。 这样，如果无法保存图像，则无需尝试回滚图库。 通常，依赖项应首先写入磁盘（或放入数据库）。

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

Answer 5

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

如果你正在编写一个内部使用的原型，如果你得到奇怪的错误，那就没关系了，那么你就是通过增加额外的检查来浪费时间和公司的钱。

另一方面，如果您正在为空中交通管制编写生产软件，那么处理所有可能的错误的额外时间可能会花费很多。

我认为这是一种权衡 - 写错误代码所花费的额外时间与处理该错误的好处，如果它发生的话。 宗教上处理每一个错误都不是最佳的IMO。