Exceptions that pop the stack versus occurring WITHIN the stack frame

In a high reliability situation where you might want to throw typed errors that are easily parsed so that you can mitigate the problem ... in such a situation, would you not at least like to throw the error WITHIN the context so that you can return to the erroring instructions?  E.g. open a file if necessary, fix a permission problem by asking the user, etc.

I.e. exceptions that can fix up, and return, as if the exception never occurred.

The other sort of exception, the C++ style exception, pops/unwinds the stack.  And can't return.   The only way that you can handle such errors is to have the calling functions loop:

Hmm..  might call this PSH versus POP exception handling.

             outer() {
                             do {
                                    bool failed = 0;
                                    try {
                                           inner();
                                     }
                                     catch(...) {
                                            // attempt fixup and repeat
                                            failed = 1;
                                      }
                              } while( failed );
               }

Imagine if you had to handle page faults in this manner?    Actually, you don't need to imagine - just look at how stack probes in old UNIX shells used to work.

This seems to be the criterion:

* if exception handling can be transparent to the calling code, you want WITHIN handling

* if exception handling requires the cooperation of the calling code, you want POP handling.

Examples of possibly transparent handling:
* page faults, where VM system can bring in
* removable disk or tape not mounted
* OS asking the user "are you sure?" before doing something that might be a security issue
* emulating unimplemented operations or instructions

Examples of non-transparent:
* stack overflow - you can't PUSH onto the present context, because there is no room left

There's a case for both.   And, certainly, if PUSH is provided, there must be a way so that it can POP.


--

Older OSes like DEC VMS(?) reportedly provided both.

Obviously OSes provided PUSH exception handling for stuff like virtual memory.

But modern languages like C++ have definitely tended towards POP or UNWIND exception handling.   If you can call C++ modern.     (Q: Java? Javascript?)

--

It almost seems that PUSH is associated with change of privilege, while POP is not.  Perhaps.  But, I would like to be able to provide things like user mode page fault handlers, or user mode integer overflow handlers.   That is only change of privilege is you have fine grain privileges, more fine than modern OSes provide.