我从不使用assert()，示例通常是这样的:

int* ptr = new int[10];
assert(ptr);

这很糟糕，我从来没有这样做过，如果我的游戏分配了一堆怪物怎么办?为什么我要让游戏崩溃，相反，你应该优雅地处理错误，所以可以这样做:

CMonster* ptrMonsters = new CMonster[10];
if(ptrMonsters == NULL) // or u could just write if(!ptrMonsters)
{
    // we failed allocating monsters. log the error e.g. "Failed spawning 10 monsters".
}
else
{
    // initialize monsters.
}

Assert非常有用，可以在出现意外错误时通过在出现问题的第一个迹象时停止程序来节省大量回溯时间。

另一方面，断言很容易被滥用。

int quotient(int a, int b){
    assert(b != 0);
    return a / b;
}

正确的说法应该是:

bool quotient(int a, int b, int &result){
    if(b == 0)
        return false;

    result = a / b;
    return true;
}

所以…从长远来看……从大局来看……我必须同意断言可能会被滥用。我一直都这么做。

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

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.

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

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

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

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

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

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

Panic将打印堆栈跟踪，因此在某种程度上它具有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.