Trying to find a compromise for the discussion in the other sub-thread here and a way to go forward.

Younger languages tend to expect the caller to at least acknowledge that an exception may be thrown with a call.

Should we introduce syntax to mark possible exceptions at the call site in C++? And the compiler may issue a warning/error in a certain safety profile, if calls are not marked?

-> Nearly all C++ function may throw, noexcept is seldom used

-> operators may be overloaded and throw

   so a whole expression or scoped block would have to be marked (that acknowledgement of possible exceptions is different to a try catch block, instead of catching it propagates and does not create runtime cost in the non-exception case)

   but if whole expressions or scoped blocks are marked, the usefulness of marking the call site is reduced; programmers need to understand the exact position of an exception to prevent unclean unwinding

Perhaps the opposite way would work better: The programmer marks a section of the program, where they assume no exception happens and the compiler proves it;

-> probably difficult to prove, if functions called in that section are usually not marked noexcept

-----Ursprüngliche Nachricht-----
Von: Sebastian Wittmeier <wittmeier@projectalpha.org>
Gesendet: So 30.08.2026 15:27
Betreff: AW: [std-proposals] fine-control exception/error/UB handling on function boundary
An: std-proposals@lists.isocpp.org;

In practice there seem to be 4 ways how modern programming-languages handle exceptions.
 

The need to sometimes propagate the errors up the call hierarchy is addressed.

Sometimes possible exceptions are marked, sometimes not, sometimes both options are offered.

Sometimes the call site, which can lead to an exception, is marked, sometimes not.

 

1. C++ exceptions / Java unchecked exceptions

==================================

 - Automatically propagate up the call stack

 - Caller does *not* have to mark at call site

 - Individual exceptions do *not* have to be listed in signature

 - In C++ function signature does not contain noexcept

 

2. Java checked exceptions

====================

 - Automatically propagate up the call stack

 - Caller does *not* have to mark at call site

 - Individual exceptions *must* be listed in signature

 

3. Swift throw

==========

 - Propagate up the call stack

 - Caller has to mark with try

 - Individual exceptions do *not* have to be listed in signature for untyped exceptions (function signature contains throw)

 - Individual exceptions *must* be listed in signature for typed exceptions

 

4. Zig try, Rust ?, Go error, C++ expected

==============================

 - Similar to 3., but error is part of return value

 - Compiler may warn/error, if return value is discarded

 - Has to be explicitly rethrown

 - Some languages offer operator to explicitly propagate