具有错误用户输入的适当库行为

Question

假设我正在编写一个库，该库以一定格式存储一系列双精度文件。格式要求双打单调增加。

现在，有些用户不会仔细阅读本手册或编写类似

之类的错误前端

store(3.0)
store(3.1)
store(0.3)
store(7.8)

图书馆可以做的是

1. 调用store(0.3)时出错。
2. 尝试通过猜测来纠正错误，例如，实际上store(3.3)。
3. 更正错误并写信给stderr。
4. [...]

（1）的优点是用户不会错过它。如果代码运行了很长时间（这是我的上下文中的常规情况），用户对程序中止不会太满意。 （2）会废除这一点，但可能会鼓励滥用图书馆。

是否有任何语言的政策提倡一种方法而不是另一种？

Answer 1

无论使用何种语言，我的一般建议是快速失败。这会将错误本地化到问题的实际来源 - 即抛出错误或异常并挽救（可能允许程序员捕获异常，具体取决于语言）。同样，某些带有已检查异常的语言可能会强制程序员添加对格式错误输入的检查。

原因很简单 - 距离错误显示的问题的实际来源越远，程序调试就越困难。让我们说程序员并不是3.3（而不是0.3）并且你为他纠正了 - 好吧，程序将继续运行，但在某些时候，值3.3将会显现并可能导致其他问题。也许这些值的来源是某种带有错误的排序算法 - 在这种情况下你的库没有失败的事实只会使调试排序算法变得更加困难并找出失败的真正原因。

对于任何对代码进行单元测试的尝试，它也会下地狱 - 失败的代码并不一定会在正确的地方失败。这只会使代码变得神奇而且难以作为开发过程的一部分进行管理。

有一种替代方法可以简单地失败并强制用户或客户端程序重新开始交互 - 您可以以事务方式执行操作，以使库在发生故障后保持一致状态，允许用户从最后一个有效输入开始（例如）。这应该通过适当的回滚语义来实现，以确保数据的一致性。

总结：快速失败，早期失败。