20.1 — The need for exceptions
When return codes fail
Exceptions
Exception handling provides a mechanism to decouple handling of errors or other exceptional circumstances from the typical control flow of your code. This allows more freedom to handle errors when and how ever is most useful for a given situation, alleviating most (if not all) of the messiness that return codes cause.
In the next lesson, we’ll take a look at how exceptions work in C++.
20.2 — Basic exception handling
In the previous lesson on the need for exceptions, we talked about how using return codes causes your control flow and error flow to be intermingled, constraining both. Exceptions in C++ are implemented using three keywords that work in conjunction with each other: throw, try, and catch.
Throwing exceptions
Putting throw, try, and catch together
Here’s a full program that uses throw, try, and multiple catch blocks:
#include <iostream>
#include <string>
int main()
{
try
{
// Statements that may throw exceptions you want to handle go here
throw -1; // here's a trivial example
}
catch (int x)
{
// Any exceptions of type int thrown within the above try block get sent here
std::cerr << "We caught an int exception with value: " << x << '\n';
}
catch (double) // no variable name since we don't use the exception itself in the catch block below
{
// Any exceptions of type double thrown within the above try block get sent here
std::cerr << "We caught an exception of type double" << '\n';
}
catch (const std::string&) // catch classes by const reference
{
// Any exceptions of type std::string thrown within the above try block get sent here
std::cerr << "We caught an exception of type std::string" << '\n';
}
std::cout << "Continuing on our merry way\n";
return 0;
}
Running the above try/catch block would produce the following result:
We caught an int exception with value -1
Continuing on our merry way
A throw statement was used to raise an exception with the value -1, which is of type int. The throw statement was then caught by the enclosing try block, and routed to the appropriate catch block that handles exceptions of type int. This catch block printed the appropriate error message.
Once the exception was handled, the program continued as normal after the catch blocks, printing “Continuing on our merry way”.
Recapping exception handling
Exception handling is actually quite simple, and the following two paragraphs cover most of what you need to remember about it:
When an exception is raised (using throw), execution of the program immediately jumps to the nearest enclosing try block (propagating up the stack if necessary to find an enclosing try block – we’ll discuss this in more detail next lesson). If any of the catch handlers attached to the try block handle that type of exception, that handler is executed and the exception is considered handled.
If no appropriate catch handlers exist, execution of the program propagates to the next enclosing try block. If no appropriate catch handlers can be found before the end of the program, the program will fail with an exception error.
Note that the compiler will not perform implicit conversions or promotions when matching exceptions with catch blocks! For example, a char exception will not match with an int catch block. An int exception will not match a float catch block. However, casts from a derived class to one of its parent classes will be performed.
That’s really all there is to it. The rest of this chapter will be dedicated to showing examples of these principles at work.
Exceptions are handled immediately
#include <iostream>
int main()
{
try
{
throw 4.5; // throw exception of type double
std::cout << "This never prints\n";
}
catch (double x) // handle exception of type double
{
std::cerr << "We caught a double of value: " << x << '\n';
}
return 0;
}
A more realistic example
#include <cmath> // for sqrt() function
#include <iostream>
int main()
{
std::cout << "Enter a number: ";
double x {};
std::cin >> x;
try // Look for exceptions that occur within try block and route to attached catch block(s)
{
// If the user entered a negative number, this is an error condition
if (x < 0.0)
throw "Can not take sqrt of negative number"; // throw exception of type const char*
// Otherwise, print the answer
std::cout << "The sqrt of " << x << " is " << std::sqrt(x) << '\n';
}
catch (const char* exception) // catch exceptions of type const char*
{
std::cerr << "Error: " << exception << '\n';
}
}
What catch blocks typically do
If an exception is routed to a catch block, it is considered “handled” even if the catch block is empty. However, typically you’ll want your catch blocks to do something useful. There are four common things that catch blocks do when they catch an exception:
First, catch blocks may print an error (either to the console, or a log file) and then allow the function to proceed.
Second, catch blocks may return a value or error code back to the caller.
Third, a catch block may throw another exception. Because the catch block is outside of the try block, the newly thrown exception in this case is not handled by the preceding try block – it’s handled by the next enclosing try block.
Fourth, a catch block in main() may be used to catch fatal errors and terminate the program in a clean way.
20.3 — Exceptions, functions, and stack unwinding
Throwing exceptions from a called function
Key insight
Try blocks catch exceptions not only from statements within the try block, but also from functions that are called within the try block.
#include <cmath> // for sqrt() function
#include <iostream>
// A modular square root function
double mySqrt(double x)
{
// If the user entered a negative number, this is an error condition
if (x < 0.0)
throw "Can not take sqrt of negative number"; // throw exception of type const char*
return std::sqrt(x);
}
int main()
{
std::cout << "Enter a number: ";
double x {};
std::cin >> x;
try // Look for exceptions that occur within try block and route to attached catch block(s)
{
double d = mySqrt(x);
std::cout << "The sqrt of " << x << " is " << d << '\n';
}
catch (const char* exception) // catch exceptions of type const char*
{
std::cerr << "Error: " << exception << std::endl;
}
return 0;
}
At this point, some of you are probably wondering why it’s a good idea to pass errors back to the caller. Why not just make MySqrt() handle its own error? The problem is that different applications may want to handle errors in different ways. A console application may want to print a text message. A windows application may want to pop up an error dialog. In one application, this may be a fatal error, and in another application it may not be. By passing the error out of the function, each application can handle an error from mySqrt() in a way that is the most context appropriate for it! Ultimately, this keeps mySqrt() as modular as possible, and the error handling can be placed in the less-modular parts of the code.
Exception handling and stack unwinding
Key insight
Unwinding the stack destroys local variables in the functions that are unwound (which is good, because it ensures their destructors execute).
Another stack unwinding example
#include <iostream>
void D() // called by C()
{
std::cout << "Start D\n";
std::cout << "D throwing int exception\n";
throw - 1;
std::cout << "End D\n"; // skipped over
}
void C() // called by B()
{
std::cout << "Start C\n";
D();
std::cout << "End C\n";
}
void B() // called by A()
{
std::cout << "Start B\n";
try
{
C();
}
catch (double) // not caught: exception type mismatch
{
std::cerr << "B caught double exception\n";
}
try
{
}
catch (int) // not caught: exception not thrown within try
{
std::cerr << "B caught int exception\n";
}
std::cout << "End B\n";
}
void A() // called by main()
{
std::cout << "Start A\n";
try
{
B();
}
catch (int) // exception caught here and handled
{
std::cerr << "A caught int exception\n";
}
std::cout << "End A\n";
}
int main()
{
std::cout << "Start main\n";
try
{
A();
}
catch (int) // not called because exception was handled by A
{
std::cerr << "main caught int exception\n";
}
std::cout << "End main\n";
return 0;
}
Take a look at this program in more detail, and see if you can figure out what gets printed and what doesn’t when it is run. The answer follows:
Start main
Start A
Start B
Start C
Start D
D throwing int exception
A caught int exception
End A
End main
20.4 — Uncaught exceptions and catch-all handlers
Uncaught exceptions
Warning
The call stack may or may not be unwound if an exception is unhandled.
If the stack is not unwound, local variables will not be destroyed, which may cause problems if those variables have non-trivial destructors.
As an aside…
Although it might seem strange to not unwind the stack in such a case, there is a good reason for not doing so. An unhandled exception is generally something you want to avoid at all costs. If the stack were unwound, then all of the debug information about the state of the stack that led up to the throwing of the unhandled exception would be lost! By not unwinding, we preserve that information, making it easier to determine how an unhandled exception was thrown, and fix it.
Catch-all handlers
#include <iostream>
int main()
{
try
{
throw 5; // throw an int exception
}
catch (double x)
{
std::cout << "We caught an exception of type double: " << x << '\n';
}
catch (...) // catch-all handler
{
std::cout << "We caught an exception of an undetermined type\n";
}
}
Because there is no specific exception handler for type int, the catch-all handler catches this exception. This example produces the following result:
We caught an exception of an undetermined type
Using the catch-all handler to wrap main()
One common use for the catch-all handler is to wrap the contents of main():
#include <iostream>
int main()
{
try
{
runGame();
}
catch(...)
{
std::cerr << "Abnormal termination\n";
}
saveState(); // Save user's game
return 1;
}
In this case, if runGame() or any of the functions it calls throws an exception that is not handled, it will be caught by this catch-all handler. The stack will be unwound in an orderly manner (ensuring destruction of local variables). This will also prevent the program from terminating immediately, giving us a chance to print an error of our choosing and save the user’s state before exiting.
The downside of this approach is that if an unhandled exception does occur, stack unwinding will occur, making it harder to determine why the unhandled exception was thrown in the first place. For this reason, using a catch-all handler in main is often a good idea for production applications, but disabled (using conditional compilation directives) in debug builds.
Best practice
If your program uses exceptions, consider using a catch-all handler in main, to help ensure orderly behavior when an unhandled exception occurs. Also consider disabling the catch-all handler for debug builds, to make it easier to identify how unhandled exceptions are occurring.
20.5 — Exceptions, classes, and inheritance
Exceptions and member functions
int& IntArray::operator[](const int index)
{
if (index < 0 || index >= getLength())
throw index;
return m_data[index];
}
Now, if the user passes in an invalid index, operator[] will throw an int exception.
When constructors fail
This is part of the reason that RAII (covered in lesson 13.9 – Destructors) is advocated so highly – even in exceptional circumstances, classes that implement RAII are able to clean up after themselves.
However, creating a custom class like Member to manage a resource allocation isn’t efficient. Fortunately, the C++ standard library comes with RAII-compliant classes to manage common resource types, such as files (std::fstream, covered in lesson 23.6 – Basic file I/O) and dynamic memory (std::unique_ptr and the other smart pointers, covered in M.1 – Introduction to smart pointers and move semantics).
For example, instead of this:
class Foo
private:
int* ptr; // Foo will handle allocation/deallocation
Do this:
class Foo
private:
std::unique_ptr<int> ptr; // std::unique_ptr will handle allocation/deallocation
In the former case, if Foo’s constructor were to fail after ptr had allocated its dynamic memory, Foo would be responsible for cleanup, which can be challenging. In the latter case, if Foo’s constructor were to fail after ptr has allocated its dynamic memory, ptr’s destructor would execute and return that memory to the system. Foo doesn’t have to do any explicit cleanup when resource handling is delegated to RAII-compliant members!
Exception classes
One way to solve this problem is to use exception classes. An exception class is just a normal class that is designed specifically to be thrown as an exception.
#include <iostream>
#include <string>
#include <string_view>
class ArrayException
{
private:
std::string m_error;
public:
ArrayException(std::string_view error)
: m_error{ error }
{
}
const std::string& getError() const { return m_error; }
};
class IntArray
{
private:
int m_data[3]{}; // assume array is length 3 for simplicity
public:
IntArray() {}
int getLength() const { return 3; }
int& operator[](const int index)
{
if (index < 0 || index >= getLength())
throw ArrayException{ "Invalid index" };
return m_data[index];
}
};
int main()
{
IntArray array;
try
{
int value{ array[5] }; // out of range subscript
}
catch (const ArrayException& exception)
{
std::cerr << "An array exception occurred (" << exception.getError() << ")\n";
}
}
Using such a class, we can have the exception return a description of the problem that occurred, which provides context for what went wrong. And since ArrayException is its own unique type, we can specifically catch exceptions thrown by the array class and treat them differently from other exceptions if we wish.
Note that exception handlers should catch class exception objects by reference instead of by value. This prevents the compiler from making a copy of the exception, which can be expensive when the exception is a class object, and prevents object slicing when dealing with derived exception classes (which we’ll talk about in a moment). Catching exceptions by pointer should generally be avoided unless you have a specific reason to do so.
Exceptions and inheritance
In order to make this example work as expected, we need to flip the order of the catch blocks:
#include <iostream>
class Base
{
public:
Base() {}
};
class Derived: public Base
{
public:
Derived() {}
};
int main()
{
try
{
throw Derived();
}
catch (const Derived& derived)
{
std::cerr << "caught Derived";
}
catch (const Base& base)
{
std::cerr << "caught Base";
}
return 0;
}
This way, the Derived handler will get first shot at catching objects of type Derived (before the handler for Base can). Objects of type Base will not match the Derived handler (Derived is-a Base, but Base is not a Derived), and thus will “fall through” to the Base handler.
Rule
Handlers for derived exception classes should be listed before those for base classes.
The ability to use a handler to catch exceptions of derived types using a handler for the base class turns out to be exceedingly useful.
std::exception
Sometimes we’ll want to handle a specific type of exception differently. In this case, we can add a handler for that specific type, and let all the others “fall through” to the base handler. Consider:
try
{
// code using standard library goes here
}
// This handler will catch std::length_error (and any exceptions derived from it) here
catch (const std::length_error& exception)
{
std::cerr << "You ran out of memory!" << '\n';
}
// This handler will catch std::exception (and any exception derived from it) that fall
// through here
catch (const std::exception& exception)
{
std::cerr << "Standard exception: " << exception.what() << '\n';
}
In this example, exceptions of type std::length_error will be caught by the first handler and handled there. Exceptions of type std::exception and all of the other derived classes will be caught by the second handler.
Such inheritance hierarchies allow us to use specific handlers to target specific derived exception classes, or to use base class handlers to catch the whole hierarchy of exceptions. This allows us a fine degree of control over what kind of exceptions we want to handle while ensuring we don’t have to do too much work to catch “everything else” in a hierarchy.
Using the standard exceptions directly
Nothing throws a std::exception directly, and neither should you. However, you should feel free to throw the other standard exception classes in the standard library if they adequately represent your needs. You can find a list of all the standard exceptions on cppreference.
std::runtime_error (included as part of the stdexcept header) is a popular choice, because it has a generic name, and its constructor takes a customizable message:
#include <exception> // for std::exception
#include <iostream>
#include <stdexcept> // for std::runtime_error
int main()
{
try
{
throw std::runtime_error("Bad things happened");
}
// This handler will catch std::exception and all the derived exceptions too
catch (const std::exception& exception)
{
std::cerr << "Standard exception: " << exception.what() << '\n';
}
return 0;
}
This prints:
Standard exception: Bad things happened
Deriving your own classes from std::exception or std::runtime_error
It’s up to you whether you want create your own standalone exception classes, use the standard exception classes, or derive your own exception classes from std::exception or std::runtime_error. All are valid approaches depending on your aims.
20.6 — Rethrowing exceptions
Throwing a new exception
One obvious solution is to throw a new exception.
int getIntValueFromDatabase(Database* d, std::string table, std::string key)
{
assert(d);
try
{
return d->getIntValue(table, key); // throws int exception on failure
}
catch (int exception)
{
// Write an error to some global logfile
g_log.logError("getIntValueFromDatabase failed");
throw 'q'; // throw char exception 'q' up the stack to be handled by caller of getIntValueFromDatabase()
}
}
In the example above, the program catches the int exception from getIntValue(), logs the error, and then throws a new exception with char value ‘q’. Although it may seem weird to throw an exception from a catch block, this is allowed. Remember, only exceptions thrown within a try block are eligible to be caught. This means that an exception thrown within a catch block will not be caught by the catch block it’s in. Instead, it will be propagated up the stack to the caller.
The exception thrown from the catch block can be an exception of any type – it doesn’t need to be the same type as the exception that was just caught.
Rethrowing an exception (the wrong way)
Rethrowing an exception (the right way)
Fortunately, C++ provides a way to rethrow the exact same exception as the one that was just caught. To do so, simply use the throw keyword from within the catch block (with no associated variable), like so:
#include <iostream>
class Base
{
public:
Base() {}
virtual void print() { std::cout << "Base"; }
};
class Derived: public Base
{
public:
Derived() {}
void print() override { std::cout << "Derived"; }
};
int main()
{
try
{
try
{
throw Derived{};
}
catch (Base& b)
{
std::cout << "Caught Base b, which is actually a ";
b.print();
std::cout << '\n';
throw; // note: We're now rethrowing the object here
}
}
catch (Base& b)
{
std::cout << "Caught Base b, which is actually a ";
b.print();
std::cout << '\n';
}
return 0;
}
This prints:
Caught Base b, which is actually a Derived
Caught Base b, which is actually a Derived
This throw keyword that doesn’t appear to throw anything in particular actually re-throws the exact same exception that was just caught. No copies are made, meaning we don’t have to worry about performance killing copies or slicing.
If rethrowing an exception is required, this method should be preferred over the alternatives.
Rule
When rethrowing the same exception, use the throw keyword by itself.
20.7 — Function try blocks
Function try blocks are designed to allow you to establish an exception handler around the body of an entire function, rather than around a block of code.
The syntax for function try blocks is a little hard to describe, so we’ll show by example:
#include <iostream>
class A
{
private:
int m_x;
public:
A(int x) : m_x{x}
{
if (x <= 0)
throw 1; // Exception thrown here
}
};
class B : public A
{
public:
B(int x) try : A{x} // note addition of try keyword here
{
}
catch (...) // note this is at same level of indentation as the function itself
{
// Exceptions from member initializer list or constructor body are caught here
std::cerr << "Exception caught\n";
throw; // rethrow the existing exception
}
};
int main()
{
try
{
B b{0};
}
catch (int)
{
std::cout << "Oops\n";
}
}
When this program is run, it produces the output:
Exception caught
Oops
Limitations on function catch blocks
Best practice
Avoid letting control reach the end of a function-level catch block. Instead, explicitly throw, rethrow, or return.
Although function level try blocks can be used with non-member functions as well, they typically aren’t because there’s rarely a case where this would be needed. They are almost exclusively used with constructors!
Function try blocks can catch both base and the current class exceptions
In the above example, if either A or B’s constructor throws an exception, it will be caught by the try block around B’s constructor.
We can see that in the following example, where we’re throwing an exception from class B instead of class A:
#include <iostream>
class A
{
private:
int m_x;
public:
A(int x) : m_x{x}
{
}
};
class B : public A
{
public:
B(int x) try : A{x} // note addition of try keyword here
{
if (x <= 0) // moved this from A to B
throw 1; // and this too
}
catch (...)
{
std::cerr << "Exception caught\n";
// If an exception isn't explicitly thrown here, the current exception will be implicitly rethrown
}
};
int main()
{
try
{
B b{0};
}
catch (int)
{
std::cout << "Oops\n";
}
}
We get the same output:
Exception caught
Oops
Don’t use function try to clean up resources
When construction of an object fails, the destructor of the class is not called. Consequently, you may be tempted to use a function try block as a way to clean up a class that had partially allocated resources before failing. However, referring to members of the failed object is considered undefined behavior since the object is “dead” before the catch block executes. This means that you can’t use function try to clean up after a class. If you want to clean up after a class, follow the standard rules for cleaning up classes that throw exceptions (see the “When constructors fail” subsection of lesson 20.5 – Exceptions, classes, and inheritance).
Function try is useful primarily for either logging failures before passing the exception up the stack, or for changing the type of exception thrown.
20.8 — Exception dangers and downsides
As with almost everything that has benefits, there are some potential downsides to exceptions as well. This article is not meant to be comprehensive, but just to point out some of the major issues that should be considered when using exceptions (or deciding whether to use them).
Cleaning up resources
The second way is to use a local variable of a class that knows how to cleanup itself when it goes out of scope (often called a “smart pointer”). The standard library provides a class called std::unique_ptr that can be used for this purpose. std::unique_ptr is a template class that holds a pointer, and deallocates it when it goes out of scope.
#include <iostream>
#include <memory> // for std::unique_ptr
try
{
auto* john { new Person("John", 18, PERSON_MALE) };
std::unique_ptr<Person> upJohn { john }; // upJohn now owns john
ProcessPerson(john);
// when upJohn goes out of scope, it will delete john
}
catch (const PersonException& exception)
{
std::cerr << "Failed to process person: " << exception.what() << '\n';
}
We’ll talk more about smart pointers in the next chapter.
Exceptions and destructors
Unlike constructors, where throwing exceptions can be a useful way to indicate that object creation did not succeed, exceptions should never be thrown in destructors.
The problem occurs when an exception is thrown from a destructor during the stack unwinding process. If that happens, the compiler is put in a situation where it doesn’t know whether to continue the stack unwinding process or handle the new exception. The end result is that your program will be terminated immediately.
Consequently, the best course of action is just to abstain from using exceptions in destructors altogether. Write a message to a log file instead.
Rule
Destructors should not throw exceptions.
Performance concerns
So when should I use exceptions?
Exception handling is best used when all of the following are true:
- The error being handled is likely to occur only infrequently.
- The error is serious and execution could not continue otherwise.
- The error cannot be handled at the place where it occurs.
- There isn’t a good alternative way to return an error code back to the caller.
As an example, let’s consider the case where you’ve written a function that expects the user to pass in the name of a file on disk. Your function will open this file, read some data, close the file, and pass back some result to the caller. Now, let’s say the user passes in the name of a file that doesn’t exist, or a null string. Is this a good candidate for an exception?
In this case, the first two bullets above are trivially met – this isn’t something that’s going to happen often, and your function can’t calculate a result when it doesn’t have any data to work with. The function can’t handle the error either – it’s not the job of the function to re-prompt the user for a new filename, and that might not even be appropriate, depending on how your program is designed. The fourth bullet is the key – is there a good alternative way to return an error code back to the caller? It depends on the details of your program. If so (e.g. you can return a null pointer, or a status code to indicate failure), that’s probably the better choice. If not, then an exception would be reasonable.
20.9 — Exception specifications and noexcept
Exception specifications are a language mechanism that was originally designed to document what kind of exceptions a function might throw as part of a function specification. While most of the exception specifications have now been deprecated or removed, one useful exception specification was added as a replacement, which we’ll cover in this lesson.
The noexcept specifier
In C++, all functions are classified as either non-throwing or potentially throwing. A non-throwing function is one that promises not to throw exceptions that are visible to the caller. A potentially throwing function may throw exceptions that are visible to the caller.
To define a function as non-throwing, we can use the noexcept specifier. To do so, we use the noexcept keyword in the function declaration, placed to the right of the function parameter list:
void doSomething() noexcept; // this function is specified as non-throwing
Note that noexcept doesn’t actually prevent the function from throwing exceptions or calling other functions that are potentially throwing. This is allowed so long as the noexcept function catches and handles those exceptions internally, and those exceptions do not exit the noexcept function.
If an unhandled exception would exit a noexcept function, std::terminate will be called (even if there is an exception handler that would otherwise handle such an exception somewhere up the stack). And if std::terminate is called from inside a noexcept function, stack unwinding may or may not occur (depending on implementation and optimizations), which means your objects may or may not be destructed properly prior to termination.
Key insight
The promise that a noexcept function makes to not throw exceptions that are visible to the caller is a contractual promise, not a promise enforced by the compiler. So while calling a noexcept function should be safe, any exception handling bugs in the noexcept function that cause the contract to be broken will result in termination of the program! This shouldn’t happen, but neither should bugs.
For this reason, it’s best that noexcept functions don’t mess with exceptions at all, or call potentially throwing functions that could raise an exception. A noexcept function can’t have an exception handling bug if no exceptions can possibly be raised in the first place!
Much like functions that differ only in their return values can not be overloaded, functions differing only in their exception specification can not be overloaded.
illustrating the behavior of noexcept functions and exceptions
// h/t to reader yellowEmu for the first draft of this program
#include <iostream>
class Doomed
{
public:
~Doomed()
{
std::cout << "Doomed destructed\n";
}
};
void thrower()
{
std::cout << "Throwing exception\n";
throw 1;
}
void pt()
{
std::cout << "pt (potentally throwing) called\n";
//This object will be destroyed during stack unwinding (if it occurs)
Doomed doomed{};
thrower();
std::cout << "This never prints\n";
}
void nt() noexcept
{
std::cout << "nt (noexcept) called\n";
//This object will be destroyed during stack unwinding (if it occurs)
Doomed doomed{};
thrower();
std::cout << "this never prints\n";
}
void tester(int c) noexcept
{
std::cout << "tester (noexcept) case " << c << " called\n";
try
{
(c == 1) ? pt() : nt();
}
catch (...)
{
std::cout << "tester caught exception\n";
}
}
int main()
{
std::cout << std::unitbuf; // flush buffer after each insertion
std::cout << std::boolalpha; // print boolean as true/false
tester(1);
std::cout << "Test successful\n\n";
tester(2);
std::cout << "Test successful\n";
return 0;
}
On the author’s machine, this program printed:
tester (noexcept) case 1 called
pt (potentially throwing) called
Throwing exception
Doomed destructed
tester caught exception
Test successful
tester (noexcept) case 2 called
nt (noexcept) called
throwing exception
terminate called after throwing an instance of 'int'
The noexcept specifier with a Boolean parameter
The noexcept specifier has an optional Boolean parameter. noexcept(true) is equivalent to noexcept, meaning the function is non-throwing. noexcept(false) means the function is potentially throwing. These parameters are typically only used in template functions, so that a template function can be dynamically created as non-throwing or potentially throwing based on some parameterized value.
Which functions are non-throwing and potentially-throwing
The noexcept operator
The noexcept operator can also be used inside functions. It takes an expression as an argument, and returns true or false if the compiler thinks it will throw an exception or not. The noexcept operator is checked statically at compile-time, and doesn’t actually evaluate the input expression.
void foo() {throw -1;}
void boo() {};
void goo() noexcept {};
struct S{};
constexpr bool b1{ noexcept(5 + 3) }; // true; ints are non-throwing
constexpr bool b2{ noexcept(foo()) }; // false; foo() throws an exception
constexpr bool b3{ noexcept(boo()) }; // false; boo() is implicitly noexcept(false)
constexpr bool b4{ noexcept(goo()) }; // true; goo() is explicitly noexcept(true)
constexpr bool b5{ noexcept(S{}) }; // true; a struct's default constructor is noexcept by default
The noexcept operator can be used to conditionally execute code depending on whether it is potentially throwing or not. This is required to fulfill certain exception safety guarantees, which we’ll talk about in the next section.
Exception safety guarantees
An exception safety guarantee is a contractual guideline about how functions or classes will behave in the event an exception occurs. There are four levels of exception safety:
- No guarantee – There are no guarantees about what will happen if an exception is thrown (e.g. a class may be left in an unusable state)
- Basic guarantee – If an exception is thrown, no memory will be leaked and the object is still usable, but the program may be left in a modified state.
- Strong guarantee – If an exception is thrown, no memory will be leaked and the program state will not be changed. This means the function must either completely succeed or have no side effects if it fails. This is easy if the failure happens before anything is modified in the first place, but can also be achieved by rolling back any changes so the program is returned to the pre-failure state.
- No throw / No fail – The function will always succeed (no-fail) or fail without throwing an exception (no-throw).
When to use noexcept
Best practice
Make constructors and overloaded assignment operators noexcept when you can. Use noexcept on other functions to express a no-fail or no-throw guarantee.
Best practice
If you are uncertain whether a function should have a no-fail/no-throw guarantee, error on the side of caution and do not mark it with noexcept. Reversing a decision to use noexcept violates an interface commitment to the user about the behavior of the function, and may break existing code. Making guarantees stronger by later adding noexcept to a function that was not originally noexcept is considered safe.
Dynamic exception specifications
The dynamic exception specifications were deprecated in C++11 and removed from the language in C++17 and C++20. See this paper for more context.
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
