Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "Why do not use exception declaration in C++". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

E.20: do not use throw exception declarations

Reason (reason)

Exception specifications make error handling brittle, impose a run-time cost, and have been removed from the C++ standard.

Throwing exception declarations makes error handling more fragile and enforces run-time costs, which have been removed from the C++ standard.

Example (sample)

Int use (int arg)

Throw (X, Y)

{

/ /...

Auto x = f (arg)

/ /...

}

If f () throws an exception different from X and Y, unexpected error handling is activated, and the default action for this handling is to terminate the program. That's fine, assuming we've checked, and this won't happen, and if f is modified to throw a new exception Z, the system will crash immediately unless we modify use () (and redo the full test). The trouble is that f () may be in a library beyond our control, and there is nothing to do or interest in the new exception use (). I can modify use () to send Z out, but then the caller of user () may need to modify it. The situation will soon get out of control. Or we can add a try-catch structure to use () to map Z to an acceptable exception. The situation will soon get out of control again. Note that group modification exceptions often occur at the bottom of the system (for example, due to changes in the network library or some middleware), so the changes are passed up the call chain like bubbles. In large-scale code, this may mean that no one can update the library to the new version until the final caller changes. If use () is part of the library, it may not be updated because you don't know who the change will affect.

The principle of allowing an exception to propagate until it is possible to handle it has been proven for many years.

Note (Note)

No. This would not be any better had exception specifications been statically enforced. For example, see Stroustrup94.

No. It is no good to insist on promoting the use of exception declaration. See also

Stroustrup. The Design and Evolution of C++ (Addison-Wesley, 1994).

Note (Note)

If no exception may be thrown, use noexcept or its equivalent throw ().

If no exception is thrown, use noexcept or its equivalent throw ()

Enforcement (implementation recommendations)

Flag every exception specification.

Mark all exception declarations that are thrown.

This is the end of the content of "Why not to use exception-throwing statement in C++". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.