Deprecated throw-list in C++11

by

For more detailed reasoning, see: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3051.html

As expressed in the national body comment above, exception specifications have not proven useful in practice. There are numerous discussions of the problems with exception specifications in C++ (see, e.g., [Sutter02], [Boost03]), but the main issues are:

  • Run-time checking: C++ exception specifications are checked at runtime rather than at compile time, so they offer no programmer guarantees that all exceptions have been handled. The run-time failure mode (calling std::unexpected()) does not lend itself to recovery.
  • Run-time overhead: Run-time checking requires the compiler to produce additional code that also hampers optimizations.
  • Unusable in generic code: Within generic code, it is not generally possible to know what types of exceptions may be thrown from operations on template arguments, so a precise exception specification cannot be written.

In practice, only two forms of exception-throwing guarantees are useful: an operation might throw an exception (any exception) or an operation will never throw any exception. The former is expressed by omitting the exception-specification entirely, while the latter can be expressed as throw() but rarely is, due to performance considerations.

[N3050] introduces a new kind of exception specification, noexcept, the specifies that the function will not throw any exceptions. Unlike throw(), noexcept does not require the compiler to introduce code to check whether an exception is thrown. Rather, if a function specified as noexcept is exited via an exception, the result is a call to std::terminate().

With the introduction of noexcept, programmers can now express the two kinds of exception guarantees that are useful in practice, without additional overhead. This paper therefore proposes to deprecate “dynamic” exception specifications, i.e., those that are written as throw(type-id-listopt).

More Related Contents:

  1. Difference between C++03 throw() specifier C++11 noexcept
  2. What is the difference between C++03 `throw()` specifier and C++11 `noexcept`?
  3. What is std::move(), and when should it be used?
  4. How does #include work in C++? [duplicate]
  5. std::function vs template
  6. Why is the destructor of a future returned from `std::async` blocking?
  7. How to return a std::string.c_str()
  8. When is a private constructor not a private constructor?
  9. C++11 “auto” semantics
  10. C++ – Why is boost::hash_combine the best way to combine hash-values?
  11. Reading from ifstream won’t read whitespace
  12. Is there a non-atomic equivalent of std::shared_ptr? And why isn’t there one in ?
  13. When is overloading pass by reference (l-value and r-value) preferred to pass-by-value?
  14. Does the GotW #101 “solution” actually solve anything?
  15. Passing shared pointers as arguments
  16. Lambda capture and parameter with same name – who shadows the other? (clang vs gcc)
  17. void_t “can implement concepts”?
  18. What are unevaluated contexts in C++?
  19. Configuring the GCC compiler switches in Qt, QtCreator, and QMake
  20. How to do serialization of Class having members of custom data types in C++? [closed]
  21. Does std::mt19937 require warmup?
  22. Why does pointer to int convert to void* but pointer to function convert to bool?
  23. Can std::vector emplace_back copy construct from an element of the vector itself?
  24. boost::asio + std::future – Access violation after closing socket
  25. reinterpret_cast between char* and std::uint8_t* – safe?
  26. Check if a type is from a particular namespace
  27. How does =delete on destructor prevent stack allocation?
  28. C++11 ‘native_handle’ is not a member of ‘std::this_thread’
  29. Does ‘auto’ type assignments of a pointer in c++11 require ‘*’?
  30. Why can’t C++11 move a noncopyable functor to a std::function?

Leave a Comment