People say “always catch exceptions by const reference,” which I think is good advice. I’ve worked on at least one codebase that catches by non-const reference, presumably just because it’s shorter to type. This has never caused any problem for them in practice, as far as I know. But in theory, it’s a bad idea, because in C++ it is possible to construct a program where two different catch-blocks, executing concurrently, actually reference the exact same exception object. In that situation, any mutation to the exception object will cause a data race. The easiest way to prevent the race is to prevent mutation: to catch by const reference!

Here’s my toy test program. We start with our exception object, which has a non-const-qualified method that mutates the object and checks to see if anyone else is mutating it at the same time (because that would mean a data race in a real program):

struct Atomic {
    std::atomic<int> value_;

    void detect_racey_accesses() {
        for (int i=0; i < 10000; ++i) {
            int last_value = value_.load();
            ++value_;
            int next_value = value_.load();
            if (next_value != last_value + 1) {
                printf("Detected a race: %d != %d+1\n", next_value, last_value);
            }
        }
    }
};

(Now, technically, concurrent calls to detect_racey_accesses do not cause data race in the C++ sense, because I’m using an atomic<int>; the data race here is at the logical level but not the physical level. In real code, where value_ would be a plain old int, we would have a physical data race here.)

And here’s the program that throws an Atomic, catches the same object by reference from two different threads, and then detects racey mutation of that object:

int main()
{
    std::promise<std::exception_ptr> prom;

    std::thread T1(
        [fut = prom.get_future()]() mutable {
            std::exception_ptr ex = fut.get();
            try {
                std::rethrow_exception(ex);
            } catch (Atomic& a) {
                a.detect_racey_accesses();  // A
            }
        }
    );
    std::thread T2(
        [prom = std::move(prom)]() mutable {
            try {
                try {
                    throw Atomic();
                } catch (...) {
                    prom.set_value(std::current_exception());
                    throw;
                }
            } catch (Atomic& b) {
                b.detect_racey_accesses();  // B
            }
        }
    );

    T1.join();
    T2.join();
}

Lines A and B run concurrently, and the object referenced by Atomic& a on line A is the exact same object as the object referenced by Atomic& b on line B.

So, catch your exceptions by const reference — and follow the “const means thread-safe” rule in your own code — and you will avoid this extremely contrived but extremely surprising situation.

This also explains why, in contrived code such as

catch (Foo& f) {
    return f;
}

we do not, and cannot, get either copy elision or implicit move on return f — it must make a copy, because the original exception object might still be in use by another thread.