我从不使用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(通常)不应该为最终产品保留。

If you build a safety net for yourself while debugging and building the system why would you deny this safety net for your customer, or your support help desk, or anyone that will get to use the software that you are currently building. Use exceptions exclusively for both asserts and exceptional situations. By creating an appropriate exception hierarchy you will be able to discern very quickly one from the other. Except this time the assert remains in place and can provide valuable information in case of failure that would otherwise be lost.

因此，我完全理解Go的创建者完全删除断言并强迫程序员使用异常来处理这种情况。对此有一个简单的解释，异常只是一种更好的工作机制为什么要坚持使用古老的断言?

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

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

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

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

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

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

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

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