我从不使用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，它就没有错。

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

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

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

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

我从不使用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让人们认为所有的调试都应该是永久性的，使用过多会导致大量的可读性问题。在需要时，永久错误处理应该比这种方法更好，由于assert会导致自己的错误，因此这是一种非常值得怀疑的实践。