If you skim the remaining rules to error handling, you often read the word noexcept. Before I write about the rules for error handling, I will write about the noexcept specifier and the noexcept operator in this post.
noexcept exists in two forms since C++11: as a specifier and as an operator. The C++ core guidelines use the specifier.
noexcept as specifier
By declaring a function, a method, or a lambda function as noexcept, you specify that these do not throw an exception, and if they throw, you do not care and let the program crash. For simplicity reasons, I will write about function but also mean methods and function templates. There are various ways to express your intention:
The noexcept specification is equivalent to the noexcept(true) specification. throw() is equivalent to noexcept(true) but was deprecated with C++11 and will be removed with C++20. In contrast, noexcept(false) means that the function may throw an exception. The noexcept specification is part of the function type but can not be used for function overloading.
There are two good reasons for using noexcept: First, an exception specifier documents the function’s behavior. If a function is specified as noexcept, it can be safely used in a non-throwing function. Second, it is an optimization opportunity for the compiler. noexcept may not call
std::unexpectedand may not unwind the stack. The initialization of a container may cheaply move the elements into the container if the move constructor is declared as noexcept. If not declared as noexcept, the elements may be expensive copied into the container.
Each function in C++ is either non-throwing or potentially throwing. Potentially throwing means:
- The function may use a function that may throw.
- The function is declared without a noexcept specification.
- The function uses a dynamic_cast to a reference type.
There is an exception to rule 2, that functions are potentially throwing if they have no noexcept specification. These exceptions include the following six special member functions. They are implicitly non-throwing.
- Default constructor and destructor
- Move and copy constructor
- Move and copy assignment operator
This special six member such as the destructor, can only be non-throwing if all destructors of the attributes and the bases-classes are non-throwing. Of course, the corresponding statement will hold for the five other special member functions.
What happens when you throw an exception in a function declared non-throwing? In this case, std::terminate is called. std::terminate calls the currently installed std::terminate_handler which calls std::abort by default.The result is an abnormal program termination.
For completeness, is want to present noexcept as operator.
noexcept as operator
noexcept operator checks at compile-time if an expression does not throw an exception. The noexcept operator does not evaluate the expression. It can be used in a noexcept specifier of a function template to declare that the function may throw exceptions depending on the current type.
To make my description clear, here is a simple example of a function template that copies its return value.
Of course, the most exciting line in this example is line (1). In particular, the expression noexcept(noexcept(T(src)). The inner noexcept ist the noexcept operator, and the outer is the noexcept specifier. The expression noexcept(T(src)) checks if the copy constructor is non-throwing.This is the case for the class Noexcept (2) but not for the class NonNoexcept (3) because of the copy constructor of std::vector that may throw. Consequently, expression (4) returns true, and expression (5) returns false.
Maybe you know about it. You can check at compile time with the help of the type traits library if a type T has a non-throwing copy constructor: std::is_nothrow_copy_constructible::value. Based on this predicate, you can use instead of the noexcept operator the predicate from the type traits library:
I don’t know which version of copy do you prefer. I prefer the type traits version because it is more expressive.
The following rule is about the noexcept specifier.
The title of this rule may be a little bit confusing. It says that you should declare a function as noexcept, if
- it does not throw or
- you don’t care in case of an exception. You are willing to crash the program because you can not handle an exception such as std::bad_alloc due to memory exhaustion.
It’s not a good idea to throw an exception if you are the direct owner of an object.
Here is an example to direct ownership from the guidelines:
If the throw is fired, the memory is lost, and you leak. The simple solution is to remove the ownership and make the C++ runtime to the direct owner of the object. Just create a local object or at least a guard as a local object. And you know the C++ runtime takes care of local objects. Here are three variations of this idea.
p1 is locally created, but p2 and p3 are kinds of guards for the objects. The std::vector uses the heap to manage its data. Additionally, with all three variations, you eliminate the delete call.
Of course, my story, with exceptions and error handling, continues in the next post.
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, and Philipp Lenk.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.
|My special thanks to Embarcadero|
|My special thanks to PVS-Studio|
|My special thanks to Tipi.build|
|My special thanks to Take Up Code|
|My special thanks to SHAVEDYAKS|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ – The Core Language
- C++ – The Standard Library
- C++ – Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,