在 Java 中使用 assert 是好的做法吗？

不使用断言的主要原因是默认情况下不启用它们。因此，如果您有一个足够重要的条件来要求断言，则不能依赖启用断言来完成工作。

正如其他答案正确指出的那样，它们是为开发时测试和调试而设计的，因为如果在生产中禁用断言，它们不会产生任何成本。我认为在测试框架中创建显式测试（例如，边缘条件的单元测试）比依靠在测试时启用断言的人更好。

但是，我看到的一个使用断言的好例子是检查私有方法参数。由于您控制了对这些方法的访问，因此您可以检查自己的类是否正确使用了该方法，而您的公共方法使用更可靠的参数检查技术（注释，if语句，第三方库等）。这样，即使禁用了断言，您的方法也应该受到保护，但是查看源代码的开发人员可以看到您的方法的前提条件，并在处理该类时打开断言以获得额外的安全网。

当我在C++中写作时，我使用的断言比在Java中使用断言的要多得多。我不经常使用它们，因为我不再需要它们了。我试图用断言来捕捉的许多C++错误在Java中不再是问题。

话虽如此，断言是非常有价值的，但许多人不怎么使用它们，部分原因是他们不理解它们。我听说有人抱怨他们抛出了错误而不是异常。我也听说过这个问题：为什么不直接使用异常并处理案例，而不是使用断言？

我对两者的答复是一样的。断言不应该捕获您希望在工作应用程序中看到的情况。断言的目的是捕获错误。您应该只在“处理”它们的唯一方法是返回并修复代码的情况下使用它们。这就是为什么它们不引发异常的原因 - 您不希望它们成为常规异常处理的一部分。

至于打开它们，我的IDE设置为默认打开它们。所以，对于我的内部测试，我总是知道他们在进行。

下面是一个断言是唯一要使用的示例：我参与了一个大型 Swing 项目，其中原始编码人员不明白 UI 只能从事件线程更新，这导致了各种错误。所以我在很多地方都放了这个断言，这些事情表现得很有趣：断言EventQueue.isDispatchThread（）;如果此断言被触发，则我们是从错误的线程运行的，并且需要通知开发人员，以便他们可以将代码移动到正确的线程。在工作应用程序中没有办法很好地处理这个问题。