在讨论这些问题时，我最近在Java中发现了 assert 关键字。起初，我很兴奋。我还不知道有用的东西！一种更有效的方法来检查输入参数的有效性！ Yay学习！
While poking around the questions, I recently discovered the assert keyword in Java. At first, I was excited. Something useful I didn't already know! A more efficient way for me to check the validity of input parameters! Yay learning!
然后我仔细看了一下，我的热情并没有像一个简单的事实那样完全被扼杀而温和：你可以关闭断言。*
But then I took a closer look, and my enthusiasm was not so much "tempered" as "snuffed-out completely" by one simple fact: you can turn assertions off.*
这听起来像是一场噩梦。如果输入 listOfStuff 是 null ，我断言我不希望代码继续运行，为什么在地球上我会想要忽略这个断言吗？听起来好像我正在调试一段生产代码并怀疑 listOfStuff 可能错误地传递了 null 但是没有看到任何触发该断言的日志文件证据，我不能相信 listOfStuff 实际上已经发送了一个有效值;我还必须考虑断言可能已完全关闭的可能性。
This sounds like a nightmare. If I'm asserting that I don't want the code to keep going if the input listOfStuff is null, why on earth would I want that assertion ignored? It sounds like if I'm debugging a piece of production code and suspect that listOfStuff may have been erroneously passed a null but don't see any logfile evidence of that assertion being triggered, I can't trust that listOfStuff actually got sent a valid value; I also have to account for the possibility that assertions may have been turned off entirely.
这假设我是调试代码的人。不熟悉断言的人可能会看到并且（非常合理地）假设如果断言消息没有出现在日志中， listOfStuff 就不会出现问题。如果你第一次遇到断言是在野外，你甚至会发现它可以完全关闭吗？它不像是一个命令行选项，让你可以禁用try / catch块。
And this assumes that I'm the one debugging the code. Somebody unfamiliar with assertions might see that and assume (quite reasonably) that if the assertion message doesn't appear in the log, listOfStuff couldn't be the problem. If your first encounter with assert was in the wild, would it even occur to you that it could be turned-off entirely? It's not like there's a command-line option that lets you disable try/catch blocks, after all.
所有这些都让我想到了我的问题（这个是一个问题，不是咆哮的借口！我保证！）：
All of which brings me to my question (and this is a question, not an excuse for a rant! I promise!):
我缺少什么？
是否有一些细微差别使得Java的断言的实现远比我给它的功劳更有用？在某些情况下，从命令行启用/禁用它的能力实际上是非常有价值的吗？当我设想在生产代码中使用它而不是像 if（listOfStuff == null）barf（）; ？
Is there some nuance that renders Java's implementation of assert far more useful than I'm giving it credit for? Is the ability to enable/disable it from the command line actually incredibly valuable in some contexts? Am I misconceptualizing it somehow when I envision using it in production code in lieu of statements like if (listOfStuff == null) barf();?
我觉得这里有一些重要的东西，我没有得到。
I just feel like there's something important here that I'm not getting.
*好的，从技术上讲，他们实际上已经离开了默认;你必须不遗余力地打开它们。但是，你仍然可以完全击败他们。 编辑：请求启示，收到启示。
*Okay, technically speaking, they're actually off by default; you have to go out of your way to turn them on. But still, you can knock them out entirely. Enlightenment requested, enlightenment received.
的概念assert 首先是一个调试工具，它对我来说是有意义的。
The notion that assert is first and foremost a debugging tool goes a long, long way towards making it make sense to me.
我仍然对应该在生产环境中禁用输入检查非平凡私有方法的概念，因为开发人员认为不可能输入错误。根据我的经验，成熟的生产代码是一种疯狂的，庞大的东西，多年来由具有不同技能的人们开发，其目标是快速变化的不同程度的理智要求。即使糟糕的输入确实是不可能的，从现在起六个月后的一段邋maintenance的维护编码也可以改变这一点。 gustafc提供的链接（谢谢！ ）包括这个例子：
I still take issue with the notion that input checks for non-trivial private methods should be disabled in a production environment because the developer thinks the bad inputs are impossible. In my experience, mature production code is a mad, sprawling thing, developed over the course of years by people with varying degrees of skill targeted to rapidly changing requirements of varying degrees of sanity. And even if the bad input really is impossible, a piece of sloppy maintenance coding six months from now can change that. The link gustafc provided (thanks!) includes this as an example:
断言间隔> 0&& interval< = 1000 / MAX_REFRESH_RATE：interval;
禁用这样一个简单的生产检查让我感到愚蠢乐观。然而，这是编码哲学的一个区别，而不是一个破碎的特征。
Disabling such a simple check in production strikes me as foolishly optimistic. However, this is a difference in coding philosophy, not a broken feature.
此外，我绝对可以看到这样的价值：
In addition, I can definitely see the value of something like this:
断言realExpensiveSanityCheck（someObject）：someObject;
感谢所有人花时间帮我理解这个功能;非常感谢。
My thanks to everybody who took the time to help me understand this feature; it is very much appreciated.
推荐答案断言是一个有用的部分按合同设计。在这种情况下，断言可用于：
assert is a useful piece of Design by Contract. In that context, assertions can be used in:
- 前提条件检查。
- 后置条件检查。
- 中间结果检查。
- 类不变检查。
- Precondition checks.
- Postcondition checks.
- Intermediate result checks.
- Class invariant checks.
判断断言的代价可能很高（例如，在调用类的任何公共方法之前和之后必须保持的类不变量）。断言通常仅在调试版本中用于测试目的;你断言那些不可能发生的事情 - 这些事情就是犯错误的同义词。断言根据自己的语义验证你的代码。
Assertions can be expensive to evaluate (take, for example, the class invariant, which must hold before and after calling any public method of your class). Assertions are typically wanted only in debug builds and for testing purposes; you assert things that can't happen - things which are synonymous of having a bug. Assertions verify your code against its own semantics.
断言不是输入验证机制。当输入真的可以在生产环境中是正确的还是错误的，即对于输入输出层，使用其他方法，例如异常或旧的条件检查。
Assertions are not an input validation mechanism. When input could really be correct or wrong in the production environment, i.e. for input-output layers, use other methods, such as exceptions or good old conditional checks.
更多推荐
Java声明断了吗？
发布评论