ERR61-CPP. Catch exceptions by lvalue reference

When an exception is thrown, the value of the object in the throw expression is used to initialize an anonymous temporary object called the exception object. The type of this exception object is used to transfer control to the nearest handler (that is, catch clause) with a matching type. The C++ Standard, [except.handle], paragraph 16 [ISO/IEC 14882-2014], states, in part:

The variable declared by the exception-declaration, of type cv T or cv T&, is initialized from the exception object, of type E, as follows:
  — if T is a base class of E, the variable is copy-initialized from the corresponding base class subobject of the exception object;
  — otherwise, the variable is copy-initialized from the exception object.

Because the variable declared by the exception-declaration is copy-initialized, it is possible to slice the exception object as part of the copy operation, losing valuable exception information and leading to incorrect error recovery. For instance, all exception types provided by the Standard Template Library inherit from std::exception, which has a virtual member function, what(), that returns implementation-defined information about the exception object. If the exception variable declared by the catch handler was sliced from the exception object created by the throw expression, calling what() on the catch handler exception variable would not result in calling what() on the exception object. For more information about object slicing, see OOP51-CPP. Do not slice derived objects.

Always catch exceptions by lvalue reference unless the type is a trivial type. For reference, the C++ Standard, [basic.types], paragraph 9 [ISO/IEC 14882-2014], defines trivial types as

Arithmetic types, enumeration types, pointer types, pointer to member types, std::nullptr_t, and cv-qualified versions of these types are collectively called scalar types.... Scalar types, trivial class types, arrays of such types and cv-qualified versions of these types are collectively called trivial types.

The C++ Standard, [class], paragraph 6, defines trivial class types as

A trivially copyable class is a class that:
  — has no non-trivial copy constructors,
  — has no non-trivial move constructors,
  — has no non-trivial copy assignment operators,
  — has no non-trivial move assignment operators, and
  — has a trivial destructor.
A trivial class is a class that has a default constructor, has no non-trivial default constructors, and is trivially copyable. [Note: In particular, a trivially copyable or trivial class does not have virtual functions or virtual base classes. — end note]

Noncompliant Code Example

In this noncompliant code example, an object of type S is used to initialize the exception object that is later caught by an exception-declaration of type std::exception. The exception-declaration matches the exception object type, and so the variable E is copy-initialized from the exception object, resulting in the exception object being sliced. Consequently, the output of this noncompliant code example is the implementation-defined value returned from calling std::exception::what() instead of "My custom exception".

#include <exception>
#include <iostream>
 
struct S : std::exception {
  const char *what() const noexcept override {
    return "My custom exception";
  }
};
 
void f() {
  try {
    throw S();
  } catch (std::exception e) {
    std::cout << e.what() << std::endl;
  }
}

Compliant Solution

In this compliant solution, the variable declared by the exception-declaration is an lvalue reference. The call to what() results in executing S::what() instead of std::exception::what().

#include <exception>
#include <iostream>
 
struct S : std::exception {
  const char *what() const noexcept override {
    return "My custom exception";
  }
};
 
void f() {
  try {
    throw S();
  } catch (std::exception &e) {
    std::cout << e.what() << std::endl;
  }
}

Risk Assessment

Object slicing can result in abnormal program execution. This generally is not a problem for exceptions, but it can lead to unexpected behavior depending on the assumptions made by the exception handler.

Automated Detection

Related Vulnerabilities

Search for other vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography