当前位置：文江博客话题详情

VERIFY(...) 是 C++ 中的良好实践吗？编码？

发布于 2024-08-29 03:14:10 字数 26 浏览 5 评论 0原文

另外，它与出现问题时抛出异常相比如何？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

已下线请稍等 2024-09-05 03:14:10

VERIFY() 与 ASSERT() （或标准库 assert()）具有相同的用途 - 让您捕获真正< em>不应该™发生（即真正的代码错误，应该在发布之前修复）。如果由于某种原因表达是错误的，那么就没有必要继续下去，因为某些事情是非常非常错误的。

这反映在以下事实：在调试模式下编译时，VERIFY() 仅在错误评估时停止程序 - 在发布模式下，它是透明的。 VERIFY() 和 ASSERT() 之间的区别在于 VERIFY() 仍然会在 Release 模式下计算表达式，它只是不会关心结果 - 而在发布模式下编译时，ASSERT() 会从程序中完全删除，因此不会发生其中表达式的任何副作用。

异常对于可能出错但可以恢复的事情更有用，因为异常可以由程序的其他部分处理。

回复收藏 0 原文

权谋诡计 2024-09-05 03:14:10

这个问题看似简单，却隐藏着一个巨大的主题：处理错误。

总之，我想说断言和验证是在开发过程中使用的工具，而异常和系统调用错误检查是生产代码的正常部分用于处理运行时错误。

断言（适用于断言和验证）是主要用于防御性编程风格的工具。他们的主要目标是防止出现不应该发生的情况，而程序员不知道如果发生这种情况该怎么办。通常它用于检查编程错误。当调试程序时发生不可能的情况时，您通常希望尽快检测并报告它。它将简化纠错。您可以在某些条件下使用它，甚至可以将其用作 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.

回复收藏 0 原文