错误检查过度杀伤？

Question

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

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

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

我确信我记得读过“不要测试那些永远不会发生的事情”的某些内容......但是不记得来源了。

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

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

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

谢谢，

詹姆斯。

Answer 1

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

Answer 2

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

  

一切都应该如此   可能无法检查失败？   或者我们应该相信那些更简单的东西   操作

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

Answer 3

我通常遵循这些规则。

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

Answer 4

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

  

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

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

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

Answer 5

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

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

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

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