Peter Dimov wrote: [... exception specifications and std::unexpected() ...]
It is not realistic to expect this behavior to be changed, but it might be possible to add another handler, separate from std::unexpected, that is invoked prior to stack unwinding.
Since that would effectively mandate two-phase EH, I'd be pretty happy (with that handler globally set to abort() in all my programs) except that ...
But I still do not understand your motivation for insisting that this is the correct way to do things. What specific practical problems does this solve?
... why-to-abort()-at-unexpected-throw-point aside for a moment, consider: struct X { int v; X() : v(0) { } ~X() { std::cout << v; } }; void f(); void g() throw() { X x; f(); x.v = 42; } with a possibility of stack unwinding due to a throw from f(), compiler has to either generate redundant initialization store (x.v = 0) or increase the size of cleanup code to let the X's destructor see 0 in x.v instead of 42 (on the path of unwinding due to a throw from f()). I don't want to have either. regards, alexander.