断言应该放在哪里？
对意外情况进行断言被认为是良好的防御性编码实践。每当我认为可能会发生意外的事情时，我就会碰巧做出断言，但现在对我来说似乎有点过分了。
此外，有时轻微的意外情况不一定会导致崩溃，甚至可能会导致客户端出现故障。
是否有一个硬性规定来提出断言？
谢谢。
Having assertions for unexpected conditions is considered to be good defensive coding practice. I happen to place assertions whenever i think something unexpected may happen, but that now seems to be an overkill to me.
Additionally, sometimes mild unexpected conditions that don't necessarily lead to crash may even cause failure on customer end.
Is there a hard and fast rule to put assertions?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
何时使用断言和异常之间的主要区别：
使用断言来捕获编程错误。如果代码编写正确，则永远不应该发生断言。
使用异常来捕获由意外环境引起的运行时错误。
如果您的程序从文件中读取脚本或内容并且它们与预期格式不匹配，我认为这是运行时条件，因此是例外。
出于调试目的，您可能决定在引发异常的地方使用断言，以便能够更轻松地找出引发异常的位置，尽管您可以使用插入 FILE 的异常宏并在消息中添加 LINE 来执行此操作。
The main difference between when to use assertions and exceptions:
Use an assertion to catch programming errors. Assertions should never happen if the code has been written correctly.
Use exceptions to catch run-time errors caused by unexpected environment.
If your program reads a script or contents from a file and they do not match the expected format, I consider that is a runtime condition therefore an exception.
You may decide, for debugging purposes, to use an assertion in the place where an exception is thrown simply to be able to work out more easily where it got thrown, although you can use exception macros that insert FILE and LINE into the message to do that too.
经常被忽视的是，断言也可以充当文档辅助工具。
因此，不仅要测试“意外”，还要使用它们来表达代码中关键点的假设（不变量）。就像
assert(high >= low)当然，让它们成为有条件的，正如其他人在这里指出的那样。
What is often overlooked is that an assert can also serve as a documentation aid.
So don't only test for the 'unexpected', also use them to express your assumptions (invariants) at critical points in your code. Like
assert(high >= low)And of course make them conditional, as others have pointed out here.
不，没有……但我绝对建议在测试和生产中以不同的方式处理断言。
在测试环境中，生成核心转储是完全可以的。它可以通过很好地安全地保留程序的整个状态来轻松检查触发断言的条件。
然而，在生产环境中，您永远不想崩溃（除非内存损坏......）。用户期望系统始终响应，没有什么比请求某些内容却从未收到响应更令人恼火的了。因此，您的工作是确保用户获得尽可能更有意义的响应，即使它是一条错误消息。实现这一点的最简单方法通常是抛出异常。
No there is not... but I would definitely recommend treating assertions differently in test and production.
It is perfectly okay, in a test environment, to produce a core dump. It allows easy inspection of the conditions that triggered the assertion by nicely safe keeping the whole state of the program.
However in a production environment, you never want to crash (except in case of memory corruption...). The user is expecting the system to always respond, there is nothing more irritating that requesting something and never receiving a response. Therefore it is your job to ensure that the user gets the more meaningful response possible, even if it is an error message. The simplest way to achieve this is usually to throw an exception.
当您非常确定在进入下一级代码之前某些条件必须为真时，就会放置断言。例如，当窗口句柄无效或某些变量没有有效值时。
Assertions are put when you are very sure that some conditions have to be true before going to the next level of your code. For example when a window handle is invalid or when some varible is not having a valid value.
从它的声音来看，您在发布版本中启用了它们。如果是这样，则创建断言级别 - 将在某些构建中启用或禁用的断言级别。然后只需使用断言级别。
这样，您无需在开发和调试版本或测试版本中关闭、关闭或删除它们。
我通常在发布时禁用它们，但它们确实消耗了大量的书面代码。我不认为这有什么不好——它充当文档并强制接口按预期使用。我认为拥有许多开发人员可能认为太多的断言是件好事，但从大局来看，实际上并没有太多断言，因为代码库不断发展，这确保了程序始终按预期使用。因此，我不建议删除它们，只需禁用发布版本的非致命检查即可。
最终，有比级别更好的方法（请参阅下面的讨论并从其他人的响应中获取您想要的内容） - 但级别是引入更改而不显着影响现有程序的一种简单方法。这将是过渡到另一个错误处理方案的好方法，或者如果您对现有方案的满意度超过 98%。
from the sounds of it, you leave them enabled in release builds. if so, create levels of assertions - those that will be enabled or disabled in certain builds. then just use an assertion level.
this way, you don't need to turn them down, off, or remove them for development and debug builds or beta releases.
i typically disable them in release, but they do consume a ton of written code. i don't think it's bad - it serves as documentation and enforces the interface to be used as intended. i think it's good to have what many devs may consider too many assertions, but there really aren't too many in the big picture because codebases evolve and this ensures that the programs are always used as intended. therefore, i don't recommend removing them, just disable the non-fatal checks for release builds.
ultimately, there are better approaches than levels (see discussion below and take what you want from others' responses) - but levels are one simple way to introduce the change without affecting existing programs considerably. this would be a good approach for a transition to another error handling scheme, or if you're >98% happy with what you have already.