不，只要您按照预期使用assert，它就没有错。

也就是说，它应该用于在调试期间捕捉“不可能发生”的情况，而不是正常的错误处理。

断言:程序逻辑本身的失败。 错误处理:错误的输入或系统状态，不是由于程序中的错误造成的。

这种情况经常出现，我认为让断言辩护令人困惑的一个问题是，它们通常基于参数检查。所以考虑一下这个不同的例子，当你使用断言时:

build-sorted-list-from-user-input(input)

    throw-exception-if-bad-input(input)

    ...

    //build list using algorithm that you expect to give a sorted list

    ...

    assert(is-sorted(list))

end

您对输入使用异常是因为您预计有时会得到错误的输入。您断言对列表进行排序是为了帮助您找到算法中的bug，根据定义，这是您所不期望的。断言只存在于调试版本中，因此即使检查的开销很大，您也不介意对例程的每次调用都进行检查。

您仍然需要对产品代码进行单元测试，但这是确保代码正确的一种不同的补充方式。单元测试确保您的例程符合其接口，而断言是一种更细粒度的方法，以确保您的实现完全按照您的期望进行。

当我看到这个的时候，我真想踢作者的头。

我在代码中一直使用断言，并最终在编写更多代码时将它们全部替换掉。当我还没有编写所需的逻辑时，我就会使用它们，当我运行到代码时，我想要得到警告，而不是编写一个将在项目接近完成时删除的异常。

异常也更容易融入到产品代码中，这是我不喜欢的。断言比抛出新异常("一些通用的msg或'pretend i am An assert'")更容易注意到;

与其说是坏事，不如说是适得其反。永久性错误检查和调试是分开的。Assert让人们认为所有的调试都应该是永久性的，使用过多会导致大量的可读性问题。在需要时，永久错误处理应该比这种方法更好，由于assert会导致自己的错误，因此这是一种非常值得怀疑的实践。

我对这些捍卫assert的答案的问题是，没有人清楚地说明它与常规致命错误的不同之处，以及为什么断言不能成为异常的子集。现在，如果异常从未被捕获，该怎么办?从命名法上看，这是一种断言吗?而且，为什么要在语言中强加一个可以引发/nothing/可以处理的异常的限制呢?

按照这种逻辑，断点也是邪恶的。

断言应该用作调试辅助，而不是其他。“邪恶”是当你试图使用它们而不是错误处理时。

断言的存在是为了帮助程序员检测和修复不可能存在的问题，并验证您的假设是否正确。

它们与错误处理无关，但不幸的是，一些程序员滥用它们，然后宣称它们是“邪恶的”。