不，去做和断言都不是坏事。但两者都可能被误用。

Assert用于完整性检查。如果它们不正确，就会杀死程序。不是为了验证或替换错误处理。

这种情况经常出现，我认为让断言辩护令人困惑的一个问题是，它们通常基于参数检查。所以考虑一下这个不同的例子，当你使用断言时:

build-sorted-list-from-user-input(input)

    throw-exception-if-bad-input(input)

    ...

    //build list using algorithm that you expect to give a sorted list

    ...

    assert(is-sorted(list))

end

您对输入使用异常是因为您预计有时会得到错误的输入。您断言对列表进行排序是为了帮助您找到算法中的bug，根据定义，这是您所不期望的。断言只存在于调试版本中，因此即使检查的开销很大，您也不介意对例程的每次调用都进行检查。

您仍然需要对产品代码进行单元测试，但这是确保代码正确的一种不同的补充方式。单元测试确保您的例程符合其接口，而断言是一种更细粒度的方法，以确保您的实现完全按照您的期望进行。

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

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

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;
}

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

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

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

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