VERIFY(...) 是 C++ 中的良好实践吗？编码？
另外，它与出现问题时抛出异常相比如何？
Also, how does it compare to throwing an exception when something goes wrong ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
另外，它与出现问题时抛出异常相比如何？
Also, how does it compare to throwing an exception when something goes wrong ?
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（3）
VERIFY()与ASSERT()（或标准库assert()）具有相同的用途 - 让您捕获真正< em>不应该™发生（即真正的代码错误，应该在发布之前修复）。如果由于某种原因表达是错误的，那么就没有必要继续下去，因为某些事情是非常非常错误的。这反映在以下事实：在调试模式下编译时，
VERIFY()仅在错误评估时停止程序 - 在发布模式下，它是透明的。VERIFY()和ASSERT()之间的区别在于VERIFY()仍然会在 Release 模式下计算表达式，它只是不会关心结果 - 而在发布模式下编译时，ASSERT() 会从程序中完全删除，因此不会发生其中表达式的任何副作用。异常对于可能出错但可以恢复的事情更有用，因为异常可以由程序的其他部分处理。
VERIFY()serves the same purpose asASSERT()(or the standard libraryassert()) - to let you catch things that really shouldn't ever™ be happening (i.e. a true code bug, something that should be fixed before release). The kinds of things that if for some reason the expression is false, there's no point to continuing because something is horribly, horribly wrong.This is reflected in the fact that
VERIFY()only stops the program on a false evaluation when compiling in Debug mode - in Release mode, it's transparent. The difference betweenVERIFY()andASSERT()is thatVERIFY()will still evaluate the expression in Release mode, it simply won't care about the result - whereasASSERT()is completely removed from the program when compiling in Release mode and thus any side-effects of the expression within it won't take place.Exceptions are more useful for things that might go wrong, but can be recovered from, since exceptions can be handled by other parts of the program.
这个问题看似简单，却隐藏着一个巨大的主题：处理错误。
总之，我想说断言和验证是在开发过程中使用的工具，而异常和系统调用错误检查是生产代码的正常部分用于处理运行时错误。
断言（适用于断言和验证）是主要用于防御性编程风格的工具。他们的主要目标是防止出现不应该发生的情况，而程序员不知道如果发生这种情况该怎么办。通常它用于检查编程错误。当调试程序时发生不可能的情况时，您通常希望尽快检测并报告它。它将简化纠错。您可以在某些条件下使用它，甚至可以将其用作
assert(false)，通常用于检查 switch 的分支是否不会被捕获。在处理我不确定其行为的第三方代码时，我主要使用断言。为了检查我自己正在开发的代码的行为，我通常更喜欢单元测试。
现在，正如薛定谔教导我们的那样，措施可以改变事情。有时，您的代码可能会在启用断言时在调试模式下工作，并在发布模式下停止工作。它通常是断言条件内隐藏错误的症状（副作用、时间敏感代码）。验证可以最大限度地减少这种风险，但这可能被认为是一种不好的做法，就像清扫地毯后面的灰尘一样。
您还可以使用验证来快速编码，作为尚未设置真正错误处理的地方的脚手架。我认为您不应该在生产代码中进行任何验证。
异常是程序控制流的正常部分。大多数情况下，它们用于处理错误，但这并不是它们唯一可能的用途（那些使用其他语言（例如 python）的人会知道我在说什么）。它们也不应该被视为唯一的错误管理工具。当未包装在 C++ 感知库中时，系统调用仍会返回错误代码，而不是引发异常。
根据经验，异常应该由能够合理处理异常的最近对象捕获。
此外，并非所有异常都应被视为致命错误并停止程序。想象一下，您正在处理一个网络视频流库，该库通过异常返回错误情况。如果库抛出一个帧被丢弃的异常警告，您通常不想停止程序，而只是为下一帧做好准备。
即使最好的办法是停止程序，您也不应该让异常为您做这件事（并且您甚至没有理由在生产代码中为此目的使用断言）。为此目的，应该始终存在一个顶级异常处理程序，它可以显式调用 exit() 等。不这样做仅仅表明程序员不关心可能发生的事情，并且可能没有考虑过它。
The question looks simple, but hides a huge subject : dealing with errors.
Summarilly I would say assert and verify are tools to use in developement process while exceptions and system calls error checking are normal parts of production code to deal with runtime errors.
Assertions (it applies to assert and verify) are tools mostly used in defensive programming style. Their main goal is to protect against cases that should never occurs and programmer has no idea of what to do if that happen. Usually it is used to check for programming errors. When the impossible happen while debugging a program you usually want to detect and report it as fast as possible. It will simplify error correction. You can use it with some condition or even as
assert(false)typically to check that a branch of a switch is never caught.I mostly use assertions when dealing with third-party code whose behavior I'm unsure. For checking behavior of my own code code under development I usually prefer unit testing.
Now, as Schroëdinger taught us, mesures change things. You may sometime have code that works in debug mode when assert is enabled and stop working in release mode. It usually is the symptom of an hidden bug inside the assertion condition (side effect, time sensitive code). Verify minimize this kind of risk, but it can be considered a bad practice, like sweeping dust behind the carpet.
You can also use verify for fast coding as scafolding for places where you didn't set up a real error handling yet. I do not believe you should let any verify in production code.
Exceptions are a normal part of program control flow. Most often they are used to deal with errors, but it's not their only possible use (those who use other languages like python will know what I'm speaking about). Neither should they be considered as the only error management tool. When not wrapped in a c++ aware library, system calls still return an error code instead of raising an Exception.
As a rule of thumb Exceptions should be caught by the nearest object that is able to handle them sensibly.
Also not all exceptions should be considered as fatal errors and stop program. Imagine you are dealing with a network video streaming library returning error cases through exceptions. It the library throw an Exception warning that a frame was dropped, you usually don't want to stop the program but just get it ready for the next frame.
Even when the best thing to do is to stop the program you should not let exception do it for you (and you have even less reason to use assert for that purpose in production code). There should always exist a top level exception handler for that purpose that makes explicit calls to exit() of like. Not doing it merely show that the programmer didn't care about what may happen and probably didn't thought about it.
在 Visual C++ 中，有两个用于检查条件的宏：
ASSERT和VERIFY。在调试模式下，它们的行为相同：也就是说，它们都评估它们的参数，如果结果为 0，它们都会通过断言失败对话框来停止程序。
区别在于发布模式。在发布模式下，
ASSERT已从程序中完全删除：它根本不评估其表达式。另一方面，VERIFY仍然评估表达式，只是忽略结果。个人，我的观点是，如果检查在调试模式下有价值，那么它在发布模式下仍然有价值，并且您可能不应该使用它们中的任何一个。只需进行测试并抛出异常（或使用在调试模式下扩展为
assert()并在发布模式下扩展为异常的自定义宏）。In Visual C++, there are two macros for checking conditions:
ASSERTandVERIFY.In debug mode, they both behave the same: that is, they both evaluate their argunment and if the result is 0, they both halt the program with an assertion failure dialog box.
The difference lies in release mode. In release, mode,
ASSERTis completely removed from the program: it doesn't evaluate it's expression at all.VERIFY, on the other hand, still evaluates the expression, it just ignores the result.Personally, my opinion is that if the check is valuable in debug mode then it's still valuable in release mode as well and you probably shouldn't use either of them. Just do the test and throw an exception (or use a custom macro that expands to
assert()in debug mode and an exception in release mode).