Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Are dynamic exception specifications invalid in c++17?

Are dynamic exception specifications invalid in c++17? Like this

void f() throw(int);
like image 851
msc Avatar asked Dec 09 '17 09:12

msc


People also ask

What is dynamic exception specification?

A dynamic exception specification whose set of adjusted types is empty (after any packs are expanded) (since C++11) is non-throwing. A function with a non-throwing dynamic exception specification does not allow any exceptions. A dynamic exception specification is not considered part of a function's type.

What is an exception specification when is it used?

Exception specifications are a C++ language feature that indicate the programmer's intent about the exception types that can be propagated by a function. You can specify that a function may or may not exit by an exception by using an exception specification.

What is dynamic exception in Java?

I presume "dynamic exception checking" might refer to catching Throwable or Exception (one of the root classes) and dynamically deciding whether to handle the exception, based on some external stimulus.

What is an exception specification Mcq?

Explanation: C++ provides a mechanism to ensure that a given function is limited to throwing only a specified list of exceptions. It is called an exception specification. ADVERTISEMENT.


2 Answers

General C++ guidelines discourages to use of exception specifications with any version of C++ and new standard has removed this feature.

E.30: Don't use exception specifications

Reason

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

Example
int use(int arg)
    throw(X, Y)
{
    // ...
    auto x = f(arg);
    // ...
}

If f() throws an exception different from X and Y the unexpected handler is invoked, which by default terminates. That's OK, but say that we have checked that this cannot happen and f is changed to throw a new exception Z, we now have a crash on our hands unless we change use() (and re-test everything). The snag is that f() may be in a library we do not control and the new exception is not anything that use() can do anything about or is in any way interested in. We can change use() to pass Z through, but now use()'s callers probably needs to be modified. This quickly becomes unmanageable. Alternatively, we can add a try-catch to use() to map Z into an acceptable exception. This too, quickly becomes unmanageable. Note that changes to the set of exceptions often happens at the lowest level of a system (e.g., because of changes to a network library or some middleware), so changes "bubble up" through long call chains. In a large code base, this could mean that nobody could update to a new version of a library until the last user was modified. If use() is part of a library, it may not be possible to update it because a change could affect unknown clients.

The policy of letting exceptions propagate until they reach a function that potentially can handle it has proven itself over the years.

Note

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

Note

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

like image 139
Marek R Avatar answered Sep 23 '22 19:09

Marek R


They are officially invalid in C++17. However, Visual C++17 with C++/Language/C++ Language Standard set to ISO C++17 still allows them. Setting warning level to 3 or higher [properties/General/Warning Level/] gives the warning,

warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)

Note that throw() is still legal and is equivalent to the newly added noexcept.

like image 27
Jive Dadson Avatar answered Sep 25 '22 19:09

Jive Dadson