The job of the spec is to as logically correct as possible.
If it can fail, you should be able to handle that failure.
In a correct program, the library should not decide on my behalf that the situation "is hopelessly unrecoverable and quit", maybe I don't want that on my software, maybe I know how to handle that. You are not going to make that decision on my behalf.


-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Frederick Virchanza Gotham via Std-Proposals
Sent: Saturday, June 6, 2026 20:03
To: std-proposals <std-proposals_at_lists.isocpp.org>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_gmail.com>
Subject: [std-proposals] Exceptions : lost all hope -- do not resuscitate

In my work this week, I submitted a pull request containing code like this:

struct S {
  optional<T> var;
  void reset(void) noexcept
  {
    lock_guard mylock{some_global_mutex};
    var.reset();
  }
}

The pull request went through code review, and a colleague of mine responded to say:

    "You've marked that function 'noexcept' but 'mutex::lock' might throw"

My response to him was:

    "If a mutex fails to lock, the entire process is fried"

Mulling over this for a bit longer, I think that the Standard should make a distinction between "normal exceptions" and "lost-all-hope exceptions".

For instance if you think a mutex might ever fail to lock in your program, I think you should do something like the following:

Step 1 - When the process starts, use 'std::fopen' to open a file on disk for writing.
Step 2 - Invoke 'std::set_terminate_handler' to register a handler that writes critical data to disk with 'std::fwrite', then 'std::fclose', and then invokes 'std::_Exit' to immediately kill the process.
Step 3 - Mark the aforementioned 'S::reset' method as 'noexcept', and just let the terminate handler save critical data if 'mutex::lock'
throws.

I don't think it's good enough that the Standard simply says that 'mutex::lock' might throw 'std::system_error', reason being that this isn't something you can just catch and recover from. If a mutex fails to lock, you need to do one of the two following:

Strategy 1 - Kill the entire process like I described above (i.e. let the terminate handler save critical data and call 'std::_Exit').

Strategy 2 - If not killing the entire process, at least mark a portion of the program as unusable -- and this is where I would use a "Do not resuscitate" flag (i.e. a DNR flag).

A few years ago when I was programming security cameras in embedded Linux, there was a background process that managed the mounting of an encrypted volume. Sometimes the encrypted volume would spontaneously unmount. We found that if you ever re-mounted the volume after it spontaneously unmounted, you would get unreliable behaviour and data corruption. For this reason I introduced a 'Do not resuscitate' flag.
If the encrypted volume were ever to spontaneously unmount, and as soon as this was detected, the DNR flag would be set -- meaning that the next time a script tried to mount the encrypted volume, the DNR flag would forbid its re-mount. This strategy minimised data corruption.

I don't think C++ programmers should be accommodating the throwing of 'std::system_error' from 'mutex::lock', for example by refraining from marking 'S::reset' as 'noexcept'. Instead, C++ should have two categories of exception -- normal exceptions and lost-all-hope exceptions. So if you were to look up "mutex::lock" on 'cppreference.com', instead of it saying:

"Throws std::system_error when errors occur, including errors from the underlying operating system that would prevent lock from meeting its specifications. The mutex is not locked in the case of any exception being thrown."

Perhaps it would say something like:

"Invokes the 'lost_all_hope' terminate handler when errors occur, including errors from the underlying operating system that would prevent lock from meeting its specifications."
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals