C++26: constexpr exceptions
In recent weeks, we’ve explored language features and library features becoming constexpr in C++26. Those articles weren’t exhaustive — I deliberately left out one major topic: exceptions. Starting with C++26, it will become possible to throw exceptions during constant evaluation. This capability is enabled through both language and library changes. Given the significance of this feature, it deserves its own dedicated post. P3068R6: Allowing exception throwing in constant-evaluation The proposal for static reflection suggested allowing exceptions in constant-evaluated code, and P3068R6 brings that feature to life. constexpr exceptions are conceptually similar to constexpr allocations. Just as a constexpr string can’t escape constant evaluation and reach runtime, constexpr exceptions also have to remain within compile-time code. Previously, using throw in a constexpr context caused a compilation error. With C++26, such code can now compile — unless an exception is actually thrown and left uncaught, in which case a compile-time error is still issued. But the error now provides more meaningful diagnostics. While no compiler supports this at the time of writing, we can walk through an example from the proposal: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 constexpr unsigned divide(unsigned n, unsigned d) { if (d == 0u) { throw invalid_argument{"division by zero"}; } return n / d; } // 1) constexpr auto b = divide(5, 0); // BEFORE: compilation error due reaching a throw expression // AFTER: still a compilation error but due the uncaught exception constexpr std::optional<unsigned> checked_divide(unsigned n, unsigned d) { try { return divide(n, d); } catch (...) { return std::nullopt; } } // 2) constexpr auto a = checked_divide(5, 0); // BEFORE: compilation error // AFTER: std::nullopt value In example 1), divide(5, 0) throws at compile time, but since the exception is uncaught, we get a compile-time error. In example 2), checked_divide catches the exception and returns a valid value — std::nullopt. This is now allowed in constant expressions. This opens up more expressive compile-time code with proper error handling paths. Can’t wait to see this in action! P3378R2: constexpr exception types Allowing exceptions in constexpr code is great — but without constexpr-enabled exception types, the usefulness would be limited. P3378R2, authored by Hana Dusíková, brings over a dozen exception types into the constexpr world. The paper is quite readable once you’ve wrapped your head around constexpr exception throwing. Here are some key takeaways: It doesn’t yet propose making all exception types constexpr, but that is the long-term goal. Future proposals involving constexpr functionality should ensure any associated exceptions are constexpr-friendly. Even std::runtime_error becomes constexpr, which is notable because it’s a common base class for many derived exceptions like std::out_of_range. Here is the list of exception types becoming constexpr-friendly: std::logic_error std::domain_error std::invalid_argument std::length_error std::out_of_range std::runtime_error std::range_error std::overflow_error std::underflow_error std::bad_optional_access std::bad_variant_access std::bad_expected_access std::format_error Conclusion C++26 is taking another big step forward in making compile-time programming more powerful and expressive. With the ability to throw and catch exceptions during constant evaluation — and with many standard exception types gaining constexpr support — developers will be able to write safer, more robust code that’s fully evaluable at compile time. Connect deeper If you liked this article, please hit on the like button, subscribe to my newsletter and let’s connect on Twitter!
