language-agnostic - 断言()与强制(): Which to choose?

Question

我很难选择我应该在 D 中“强制”一个条件还是“断言”一个条件。(不过，这是语言中立的。)

从理论上讲，我知道您使用断言来查找错误，并强制执行其他条件以检查非典型条件。例如。你可能会说 assert(count >= 0)对于您的方法的参数，因为这表明调用者存在错误，并且您会说 enforce(isNetworkConnected) ，因为这不是一个错误，它只是你假设的事情，在你无法控制的合法情况下很可能不是真的。

此外，断言可以作为优化从代码中删除，没有副作用，但无法删除强制执行，因为它们必须始终执行其条件代码。因此，如果我正在实现一个惰性填充容器，该容器在第一次访问其任何方法时填充自身，我会说 enforce(!empty())而不是 assert(!empty()) ，因为检查 empty()必须总是发生，因为它懒惰地执行里面的代码。

所以我想我知道他们应该是这个意思。但是理论比实践容易，我很难实际应用这些概念。

考虑以下:

我正在创建一个范围(类似于迭代器)，它在其他两个范围内进行迭代，并添加结果。 (对于函数式程序员:我知道我可以使用 map!("a + b") 代替，但我现在忽略它，因为它没有说明问题。)所以我的伪代码如下所示:

void add(Range range1, Range range2)
{
    Range result;
    while (!range1.empty)
    {
        assert(!range2.empty);   //Should this be an assertion or enforcement?
        result += range1.front + range2.front;
        range1.popFront();
        range2.popFront();
    }
}

这应该是断言还是强制执行？ (范围没有同时为空是调用者的错吗？它可能无法控制范围的来源——它可能来自用户——但话又说回来，它看起来仍然像一个错误，不是吗？)

或者这是另一个伪代码示例:

uint getFileSize(string path)
{
    HANDLE hFile = CreateFile(path, ...);
    assert(hFile != INVALID_HANDLE_VALUE); //Assertion or enforcement?
    return GetFileSize(hFile); //and close the handle, obviously
}
...

这应该是断言还是强制执行？路径可能来自用户——因此它可能不是错误——但路径应该有效仍然是此方法的先决条件。我是主张还是强制执行？

谢谢!

Answer 1

我不确定它是否完全与语言无关。我使用的任何语言都没有 enforce() ，如果我遇到了，那么我想使用 assert和 enforce以它们预期的方式，这可能是该语言的惯用方式。

例如 assert在 C 或 C++ 中，当程序失败时停止程序，它不会抛出异常，因此它的用法可能与您所说的不一样。你不使用 assert在 C++ 中，除非您认为调用者已经犯了一个严重到不能依靠他们来清理的错误(例如传入一个负数)，或者其他地方的一些其他代码犯了一个非常严重的错误，以至于程序应被视为处于未定义状态(例如，您的数据结构似乎已损坏)。不过，C++ 确实区分了运行时错误和逻辑错误，它们可能大致对应，但我认为主要是关于可避免和不可避免的错误。

在add的情况下如果作者的意图是提供不匹配列表的程序存在错误并需要修复，或者运行时异常只是可能发生的事情之一，那么您将使用逻辑错误。例如，如果您的函数要处理任意生成器，而不必报告它们的长度而不是破坏性地评估整个序列，则您更有可能将其视为不可避免的错误情况。

将其称为逻辑错误意味着调用者有责任在调用 add 之前检查长度。 ，如果他们不能通过纯粹的理由来确保它。所以他们不会在没有首先明确检查长度的情况下传递来自用户的列表，老实说，他们应该认为自己很幸运，他们甚至遇到了异常而不是未定义的行为。

将其称为运行时错误表示传入不同长度的列表是“合理的”(如果异常)，但异常表明它发生在这种情况下。因此，我认为是强制执行而不是断言。

在filesize的情况下:对于文件的存在，如果可能，您应该将其视为潜在的可恢复故障(强制执行)，而不是错误(断言)。原因很简单，调用者无法确定某个文件是否存在——在检查是否存在和调用filesize .因此，当它不存在时，它不一定是调用代码中的逻辑缺陷(尽管最终用户可能已经将自己射中了自己的脚)。由于这个事实，很可能会有调用者将其视为发生的事情之一，这是一种不可避免的错误情况。创建文件句柄也可能因内存不足而失败，这是大多数系统上另一个不可避免的错误，尽管如果启用了过度提交，则不一定是可恢复的错误。

另一个需要考虑的例子是 operator[]对比 at()对于 C++ 的向量。 at()抛出 out_of_range , 一个逻辑错误，不是因为调用者可能想要恢复是不可想象的，或者因为你必须是某种 NumPy 才能犯使用 at() 访问超出范围的数组的错误，但是因为如果调用者希望错误是完全可以避免的 - 您可以随时检查 size()如果您没有其他方法知道您的索引是否良好，则在访问之前。等等 operator[]根本不保证任何检查，并且以效率的名义，超出范围的访问具有未定义的行为。