1

假设我正在编写一个库，它将一系列双精度数据以某种格式存储到文件中。该格式要求双打单调递增。

现在，一些用户不会仔细阅读手册或编写错误的前端来执行类似的操作

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) 会取消这一点，但可能会鼓励滥用图书馆。

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

4

1 回答 1

1

不管使用什么语言，我的一般建议是总是快速失败。这会将错误定位到问题的实际根源——即，抛出错误或异常并退出（可能允许程序员捕获异常，具体取决于语言）。类似地，一些带有检查异常的语言可能会迫使程序员添加对格式错误的输入的检查。

原因很简单——离错误所表现的问题的实际来源越远，程序就越难调试。假设程序员不是故意的3.3（而不是0.3），而您为他纠正了它 - 好吧，程序将继续运行，但在某些时候该值3.3会表现出来并可能导致其他问题。也可能是这些值的来源是某种带有错误的排序算法 - 在这种情况下您的库不会失败的事实只会使调试排序算法和识别失败的真正原因变得更加困难。

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

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

总而言之：快速失败，早点失败。

于 2012-08-31T13:48:16.797 回答