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

我承认使用了断言，但没有考虑适当的错误报告。然而，这并不意味着它们在正确使用时是非常有用的。

They are especially useful for if you want to follow the "Crash Early" principle. For example suppose you're implementing a reference counting mechanism. At certain locations in your code you know that the refcount should be zero or one. And also suppose that if the refcount is wrong the program won't crash immediately but during the next message loop at which point it will be difficult to find out why things went wrong. An assert would have been helpful in detecting the error closer to its origin.

我更倾向于避免在调试和发布中做不同事情的代码。

但是，在一个条件下中断调试器并获得所有文件/行信息，以及确切的表达式和确切的值是有用的。

拥有一个“只在调试中评估条件”的断言可能是一种性能优化，因此，它只在0.0001%的程序中有用——人们知道他们在做什么。在所有其他情况下，这是有害的，因为表达式实际上可能改变程序的状态:

assert(2 == shroedingerscat . getnummears ()); 会使程序在调试和发布时做不同的事情。

我们开发了一组assert宏，可以在调试版和发布版中抛出异常。例如，THROW_UNLESS_EQ(a, 20);what()消息同时包含文件、行和a的实际值，等等，将抛出异常。只有宏才有这个功能。调试器可以配置为在特定异常类型的'throw'时中断。

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

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

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

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

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

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

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

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

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

断言的一些替代方法:

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

参考:

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.