你使用断言吗？
这实际上并不是一个“问题”，所以我将其设为 CW。
关键字
assert
太棒了！
它应该让您对自己编写的代码更加自信，但是，直到今天我创建一个小型测试类（< 20 行）时，我意识到自从引入它以来就从未使用过它。
哎呀！ 我几乎不使用记录器，这确实非常有用，但直到今天我才意识到我不使用断言。
你使用断言吗？ 如果不是，原因是什么？
This is not really a "question" so I'm making it CW.
The
assert
Keyword is great!
It should make, feel your self more confident with the code you wrote, but, until today when I was creating a small test class ( < 20 lines ) I realize a never use it since it was introduced.
Heck! I barely use logger which is very useful indeed, but it wasn't until today I realize I don't use assertions.
Do you use assertions? If no, what's the reason?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（16）
不，但等不及了。 我曾经用junit对所有东西进行单元测试，但那是学校，小项目没有压力。 我现在在现实生活中，我应该昨天完成这段代码......
No. But can't wait. I used to unit test everything with junit, but that was school, small projects no pressure. i'm in real life now, i supposed to finish this code yesterday....
我从来没有使用过它们，但我在调试上一个程序时经历了一段糟糕的时间，并且在某个时候记录变量为空或不包含我期望的值。 一旦我让一切正常工作，我就断言了我的程序成功运行所需的一切。
I never used to use them, but I had an awful time debugging my last program, and at one point was logging when variables were null or didn't contain the values that I would expect. Once I'd got it all working I asserted everything that my program needed in order to run successfully.
我倾向于检查错误条件并抛出异常。 原因是我希望始终检查这些条件，即使在生产中也是如此，并且异常比断言更容易处理失败的条件。
I tend to check for error conditions and throw exceptions instead. The reason is that I want these conditions to always be checked, even in production, and exceptions provide for easier handling of the failed condition rather than assertions.
Java 断言关键字相当半途而废（需要使用 -ea 命令行选项运行程序），因此我发现自己依赖于异常而不是断言。
The Java assert keyword is pretty half assed (need to run the program with the -ea commandline option) so I find myself relying on exceptions instead of asserts.
我倾向于不使用它们，尽管我也不确定为什么。
如果您进行单元测试（例如使用 nUnit），您显然会一直使用它们来验证您的测试结果。
I tend not to use them, although I'm not sure why either.
If you do unit testing, such as with nUnit, you would obviously use them all the time to verify your test results.
不，我不使用它们。
我被教导，断言不应该在“生产”代码中使用，并且在我开始使用无论如何都必须删除的东西之前 - 根据我所学到的 - 我坚持使用异常来验证条件。
No, I don't use them.
I was taught, that asserts should not be used in 'production' code, and before I start using something that I have to remove anyway - according to what I've learned - I stick with exception to validate conditions.
是的！ 总是！ 在每种语言中，关键字都是我最好的朋友！
没有真正的理由不使用断言，它们确保我对输入值和状态所做的基本假设得到维护。
如果断言失败，则意味着我需要重新评估我的假设并更新代码以处理我在编写当前版本时没有想到的新的外来输入。 有什么不喜欢的呢？
与编程中通常的情况一样，只有正确使用它才是一个强大的工具。
Yes! Always! The keyword is my very best friend in every language!
There's no real reason not to use asserts, they ensure that the basic assumptions I make on input values and states are upheld.
If an assert fails, it means that I need to re-evaluate my assumptions and update the code to handle new exotic input that I did not think of when writing the current revision. What's not to like about that?
As usual in programming, it's a tool that's powerful only when used properly.
是的，我一直使用断言，基本上每当我做出以下假设时：
但是，对于可能对性能影响可以忽略不计的断言，我使用 D 编程语言标准库中的
enforce函数而不是assert。 这与assert 的作用基本相同，只是它保持在发布模式。 对于更昂贵的断言，我使用assert，它从发布模式构建中删除。Yes, I use asserts all the time, basically whenever I'm making an assumption that:
However, for asserts that are likely to have a negligible impact on performance, I use the
enforcefunction in the D programming language standard library instead ofassert. This does basically the same thing asassertexcept that it stays around in release mode. For more expensive assertions, I useassert, which is stripped from release mode builds.不，永远不要使用它们。 不知道为什么，就是一直没养成这个习惯。
Nope, never use them. Dunno why, just never got into the habit.
如果您喜欢断言，您就会喜欢合约。 它们基本上是将断言的想法扩展到更多情况。
If you like asserts, you'll LOVE contracts. They are basically the idea of asserts extended to more situations.
我不使用它们。 单元测试应该足以测试您的代码。 此外，由于默认情况下它们是禁用的，因此通常会完全忽略它们。 然后，他们只会用无用的断言弄乱您的代码，而这些断言可以更好地表达为注释。
不过，如果您确实需要这个，某些库具有您可以调用的断言静态方法，这些方法不会被跳过 - 这些方法也更具可读性，因为断言关键字不常见，并且可能会立即导致“ wtf”时刻，但 Assert.x 方法只是可以追踪的方法。 Spring 框架尤其使用断言库。
I don't use them. Unit tests should be sufficient to test your code. Furthermore, since they're disabled by default, they're normally completely ignored anyways. Then they just tend to clutter up your code with useless assertions that could be better expressed as comments.
If you really need this, though, some libraries have assertion static methods you can call that will not be skipped - these are also a lot more readable, because the assert keyword is uncommon and immediately may cause a "wtf" moment, but the Assert.x methods are just methods that can be traced through. The Spring framework, in particular, uses an assertion library.
引入单元测试后，断言的唯一真正用途是将方法的不变量传达给其他程序员。 在实际代码中执行此操作比在注释中执行要好得多，因为无论如何他们都会忽略注释。 很难忽视一个断言！
The only real use for assertions after unit testing was introduced is to communicate the invariant of a method to other programmers. And it is much better to do this in actual code than in comments which they will ignore anyway. It is hard to ignore an assert!
简短的回答 - 是的。
长答案 - 并非总是如此，但经常如此。 我通常对我知道我无能为力的错误使用断言（当程序运行时），并且实际上并不需要日志记录。 例如 - 如果我必须检查某个值是否超出范围，或者指针是否为 NULL，即使它应该有某个值。
对于“正在解析文件”和“找不到文件”等其他内容，我通常会抛出异常。 这样我就可以记录错误并使用一些故障安全文件/方法来代替。
我非常同意 Falaina 的观点，你真的应该注意这一点 - “嘿！我在这里做了一些假设”
Short answer - Yes.
Long Answer - Not always, but quite often. I usually use assertions for errors I know I can do nothing about(while the program is running) and logging isn't really required. For example - If I have to check if a certain value is out of bounds or if a pointer is NULL even though it should have some value.
For other stuff like "Parsing files" and "File couldn't be found", I usually throw exceptions. That way I can log the error and use some fail safe file/method instead.
And I quite agree with with Falaina, you really should make it a point to notice - "HEY! I'm making some assumptions here"
我一直在使用它们。 它们是实践“尽早崩溃”哲学的好方法，最好是解决断言失败的原因，而不是处理错误/损坏的输出。
问题是你必须让它成为一种习惯。 我很少看到其中有任何中间立场，人们要么不习惯它并且几乎从不使用它们，要么人们使用它们并且它们在整个代码中严格散布。 你只需要注意“哦嘿，我隐含地假设了一些东西，让我明确地确认它‘断言（假设）’”
I use them all the time. They're a nice way to practice the "Crash early" philosophy, better to have to solve why an assertion failed than to have to deal with bad/corrupted output.
The issue is you have to kind of make it a habit. I rarely see any middle ground in it, people are either not used to it and almost never use them or people use them and they're littered rigorously throughout the code. You just have to get into the mindset of noticing "Oh hey, I'm implicity assuming something here, let me explicitly confirm it 'assert(ASSUMPTION)'"
我使用断言来确保我不会在代码中引入错误。 如果我知道某个值应该位于映射中，我会对此进行断言（使用assert 关键字）。 如果我知道参数永远不应该为空，我会断言这一点。 如果我知道该参数可以为空，那么我将检查它并抛出适当的异常。
我在《Code Complete》或《Effective Java》中读过它 - 断言应该用于检测编程错误 - 异常应该用于处理异常但可能的情况。 如果您知道该值不会为 null（如合同所定义），则无需在代码中的每个方法上检查 null，但断言值是否不为 null 也没什么坏处。 仅当您向 VM 指定参数 -ea 时，才会启用断言，并且如果禁用，断言不应影响应用程序的性能。
您也应该使用更多日志记录:-)。 了解何时使用跟踪、调试和信息，并确保记录应用程序执行的所有操作。 当您必须弄清楚为什么某些东西在生产环境中不起作用时，它会让生活变得更加轻松。
I use assertions to make sure that I don't introduce errors in my code. If I know that a value should be in a map, I assert for that (using the assert keyword). If I know that a parameter should never be null, I assert for that. If I know that the parameter can be null, then I will check it and throw the appropriate exception.
I read it at Code Complete or Effective Java - assertions should be used to detect programming errors - exceptions should be used to handle exceptional but possible situations. You don't need to check for null on every method on your code if you know that the value will not be null (as defined by a contract), but it doesn't hurt to assert if a value is not null. Assertions are only enabled if you specify the parameter -ea to the VM and they should not impact the performance of your application if disabled.
You should use more logging too :-). Learn when to use trace, debug and info and make sure that you log everything that your application does. It makes life so easier when you have to figure out why something is not working in a production environment.
早在 90 年代，我就被教导要使用很多断言，它们非常有意义。 这是很好的防御性编码。
然而，我认为这现在已经被单元测试所取代，单元测试实际上强制代码运行并告诉它哪里被破坏了。 调试断言需要有人实际运行调试代码并查看用户界面或日志。 单元测试可以自动化这一点。
I was taught to use lots of assertions back in the 90s and they made great sense. It's good defensive coding.
However, I think this has now been superceded by unit testing that actually forces the code to run and tells where it is broken. Debug asserts required someone to actually be running debug code and looking at the ui or logs. Unit testing can automate this.