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

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

不，只要您按照预期使用assert，它就没有错。

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

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

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

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

是的，断言是邪恶的。

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

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

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

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

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

我对这些捍卫assert的答案的问题是，没有人清楚地说明它与常规致命错误的不同之处，以及为什么断言不能成为异常的子集。现在，如果异常从未被捕获，该怎么办?从命名法上看，这是一种断言吗?而且，为什么要在语言中强加一个可以引发/nothing/可以处理的异常的限制呢?

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

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

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