如果您所谈论的断言意味着程序抛出然后存在，那么断言可能非常糟糕。这并不是说它们总是错误的使用，它们是一种很容易被误用的结构。他们也有很多更好的选择。这样的事情很容易被称为邪恶。

例如，第三方模块(或任何模块)几乎不应该退出调用程序。这并没有给调用程序的程序员任何控制程序此时应该承担的风险。在许多情况下，数据是如此重要，即使保存损坏的数据也比丢失数据要好。断言可能会迫使您丢失数据。

断言的一些替代方法:

使用调试器， 控制台/数据库/其他日志 异常 其他类型的错误处理

参考:

http://ftp.gnu.org/old-gnu/Manuals/nana-1.14/html_node/nana_3.html http://www.lenholgate.com/blog/2005/09/assert-is-evil.html Go不提供断言，并且有很好的理由:http://golang.org/doc/faq#assertions http://c2.com/cgi/wiki?DoNotUseAssertions

甚至主张assert的人也认为它们应该只用于开发而不是生产:

http://codebetter.com/gregyoung/2007/12/12/asserts-are-not-evil/ http://www.codeproject.com/Articles/6404/Assert-is-your-friend http://parabellumgames.wordpress.com/using-asserts-for-debugging/

This person says that asserts should be used when the module has potentially corrupted data that persists after an exception is thrown: http://www.advogato.org/article/949.html . This is certainly a reasonable point, however, an external module should never prescribe how important corrupted data is to the calling program (by exiting "for" them). The proper way to handle this is by throwing an exception that makes it clear that the program may now be in an inconsistent state. And since good programs mostly consist of modules (with a little glue code in the main executable), asserts are almost always the wrong thing to do.

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

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

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

断言并不邪恶，但很容易被滥用。我非常同意“断言经常被用作一种拐杖，以避免考虑正确的错误处理和报告”的说法。我经常看到这种情况。

就我个人而言，我确实喜欢使用断言，因为它们记录了我在编写代码时可能做出的假设。如果在维护代码时这些假设被打破了，那么可以在测试期间检测到问题。但是，在进行产品构建时(即使用#ifdefs)，我确实强调要从代码中剥离出每个断言。通过剥离产品构建中的断言，我消除了任何人将其误用为拐杖的风险。

断言还有另一个问题。断言只在运行时进行检查。但是通常情况下，您想要执行的检查可以在编译时执行。最好在编译时检测问题。对于c++程序员，boost提供了BOOST_STATIC_ASSERT，它允许您执行此操作。对于C程序员，本文(链接文本)描述了一种可用于在编译时执行断言的技术。

总之，我遵循的经验法则是:不要在生产构建中使用断言，如果可能的话，只对在编译时无法验证的东西使用断言(即，必须在运行时检查)。

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

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，根据定义，这是您所不期望的。断言只存在于调试版本中，因此即使检查的开销很大，您也不介意对例程的每次调用都进行检查。

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

我很喜欢用断言。我发现当我第一次构建应用程序(可能是一个新的领域)时，它非常有用。我没有做非常花哨的错误检查(我认为是不成熟的优化)，而是快速编码，并添加了大量断言。在我了解了更多事情的工作原理后，我重新编写并删除了一些断言并更改它们以更好地处理错误。

因为断言，我花更少的时间编码/调试程序。

我还注意到，断言可以帮助我想到许多可能破坏程序的东西。

作为附加信息，go提供了一个内置函数panic。这可以用来代替assert。如。

if x < 0 {
    panic("x is less than 0");
}

Panic将打印堆栈跟踪，因此在某种程度上它具有assert的目的。