在 C + + 中使用声明()是不好的做法吗？

我倾向于在我的 C + + 代码中添加大量的断言，以便在不影响发布版本性能的情况下使调试更加容易。现在，assert是一个纯 C 宏，设计时没有考虑 C + + 机制。

另一方面，C + + 定义了 std::logic_error，这意味着在程序逻辑出错的情况下抛出 std::logic_error(因此得名)。抛出一个实例可能是 assert的完美的、更像 C + + 的替代品。

问题是，assert和 abort都会立即终止程序，而不调用析构函数，因此会跳过清理，而手动抛出异常会增加不必要的运行时成本。解决这个问题的一种方法是创建一个自己的断言宏 SAFE_ASSERT，它的工作方式与 C 语言相同，但在出现故障时抛出异常。

关于这个问题，我可以想出三种观点:

  • 坚持 C 的断言。由于程序立即终止，所以更改是否正确展开并不重要。而且，在 C + + 中使用 #define也一样糟糕。
  • 抛出一个异常并在 main () 中捕获它。允许代码在程序的任何状态下跳过析构函数都是不好的做法，必须不惜一切代价避免这种情况，对 finally ()的调用也是如此。如果引发异常，则必须捕获它们。
  • 抛出一个异常并让它终止程序。异常终止程序是可以的，而且由于 NDEBUG的原因，在发布版本中永远不会发生这种情况。捕获是不必要的，并将内部代码的实现细节暴露给 main()。

这个问题有明确的答案吗? 有专业的参考吗？

编辑: 跳过析构函数当然不是未定义的行为。

49036 次浏览
小开
最佳答案

Assertions are entirely appropriate in C++ code. Exceptions and other error handling mechanisms aren't really intended for the same thing as assertions.

Error handling is for when there's a potential for recovering or reporting an error nicely to the user. For example if there's an error trying to read an input file you may want to do something about that. Errors could result from bugs, but they could also simply be the appropriate output for a given input.

Assertions are for things like checking that an API's requirements are met when the API wouldn't normally be checked, or for checking things the developer believes he's guaranteed by construction. For example if an algorithm requires sorted input you wouldn't normally check that, but you might have an assertion to check it so that debug builds flag that kind of bug. An assertion should always indicate an incorrectly operating program.

If you're writing a program where an unclean shutdown could cause a problem then you may want to avoid assertions. Undefined behavior strictly in terms of the C++ language doesn't qualify as such a problem here, since hitting an assertion is probably already the result of undefined behavior, or the violation of some other requirement which could prevent some clean-up from working properly.

Also if you implement assertions in terms of an exception then it could potentially be caught and 'handled' even though this contradicts the very purpose of the assertion.

小开

  • Assertions are for debugging. The user of your shipped code should never see them. If an assertion is hit, your code needs to be fixed.

    CWE-617: Reachable Assertion

The product contains an assert() or similar statement that can be triggered by an attacker, which leads to an application exit or other behavior that is more severe than necessary.

While assertion is good for catching logic errors and reducing the chances of reaching more serious vulnerability conditions, it can still lead to a denial of service.

For example, if a server handles multiple simultaneous connections, and an assert() occurs in one single connection that causes all other connections to be dropped, this is a reachable assertion that leads to a denial of service.

  • Exceptions are for exceptional circumstances. If one is encountered, the user won't be able to do what she wants, but may be able to resume somewhere else.

  • Error handling is for normal program flow. For instance, if you prompt the user for a number and get something unparsable, that's normal, because user input is not under your control and you must always handle all possible situations as a matter of course. (E.g. loop until you have a valid input, saying "Sorry, try again" in between.)

小开

Not running destructors due to alling abort() is not undefined behaviour!

If it were, then it would be undefined behaviour to call std::terminate() too, and so what would be the point in providing it?

assert() is just as useful in C++ as in C. Assertions are not for error handling, they're for aborting the program immediately.

小开

Assertions can be used to verify internal implementation invariants, like internal state before or after execution of some method, etc. If assertion fails it really means the logic of the program is broken and you can't recover from this. In this case the best you can do is to break as soon as possible without passing exception to the user. What is really nice about assertions (at least on Linux) is that core dump is generated as a result of process termination and thus you can easily investigate the stack trace and variables. This is much more useful to understand the logic failure than exception message.

小开

IMHO, assertions are for checking conditions that if violated, make everything else nonsense. And therefore you cannot recover from them or rather, recovering is irrelevant.

I would group them into 2 categories:

  • Developer sins (e.g. a probability function that returns negative values ):

float probability() { return -1.0; }

assert(probability() >= 0.0)

  • The Machine is broken (e.g. the machine which runs your program is very wrong):

int x = 1;

assert(x > 0);

These are both trivial examples but not too far from reality. For example, think about naive algorithms that return negative indexes for using with vectors. Or embedded programs in custom hardware. Or rather because sh*t happens.

And if there is such development mistakes you should not be confident about any recovering or error handling mechanism implemented. The same applies for hardware errors.


提交答案