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

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

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

我从不使用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.
}

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

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.

Assert被滥用用于错误处理，因为它的输入更少。

因此，作为语言设计者，他们应该看到，适当的错误处理可以用更少的输入完成。因为异常机制太冗长而排除assert并不是解决方案。哦，等等，Go也没有异常。太糟糕了:)

是的，断言是邪恶的。

它们通常用于应该使用正确错误处理的地方。从一开始就要习惯编写正确的产品质量错误处理程序!

通常它们会妨碍编写单元测试(除非您编写了与测试工具交互的自定义断言)。这通常是因为它们被用于应该使用正确错误处理的地方。

大多数情况下，它们是从发布版本中编译出来的，这意味着当你运行实际发布的代码时，它们的“测试”是不可用的;考虑到在多线程情况下，最糟糕的问题通常只出现在发布代码中，这可能很糟糕。

有时，他们是一个拐杖，否则破碎的设计;也就是说，代码的设计允许用户以一种不应该被调用的方式调用它，而断言“阻止”了这一点。修改设计!

早在2005年，我就在我的博客http://www.lenholgate.com/blog/2005/09/assert-is-evil.html上写过更多关于这方面的内容

我最近开始在我的代码中添加一些断言，这是我一直在做的:

我在心里把代码分为边界代码和内部代码。边界代码是处理用户输入、读取文件和从网络获取数据的代码。在这段代码中，我在一个循环中请求输入，该循环仅在输入有效时退出(在交互式用户输入的情况下)，或者在不可恢复的文件/网络损坏数据的情况下抛出异常。

内部代码就是一切。例如，在我的类中设置变量的函数可以定义为

void Class::f (int value) {
    assert (value < end);
    member = value;
}

从网络获取输入的函数可以这样读:

void Class::g (InMessage & msg) {
    int const value = msg.read_int();
    if (value >= end)
        throw InvalidServerData();
    f (value);
}

This gives me two layers of checks. Anything where the data is determined at run-time always gets an exception or immediate error handling. However, that extra check in Class::f with the assert statement means that if some internal code ever calls Class::f, I still have a sanity check. My internal code might not pass a valid argument (because I may have calculated value from some complex series of functions), so I like having the assertion in the setting function to document that regardless of who is calling the function, value must not be greater than or equal to end.

这似乎符合我在一些地方读到的内容，即在一个功能良好的程序中，断言应该是不可能违反的，而例外应该是针对仍然可能发生的异常和错误情况。因为理论上我要验证所有输入，所以我的断言不应该被触发。如果是，我的程序就错了。