🚀 go-pugleaf

In article 95Sep19103925@physics3.Berkeley.EDU, "Daniel S. Barclay" <daniel@compass-da.com> writes:
>
>In the design of exceptions and exception handling, has the language
>design committee (or implementors or whoever) reviewed VAX/VMS exception 
>handling and its capabilities?  
>
>I've noticed one thing that the C++ draft's exception mechanism does not 
>(seem to) support that VAX/VMS supports (or at least used to; I haven't used 
>VMS for 6 years).
>
>In VMS exception handling, the stack is not unwound before traversing upwards
>to find the applicable exception handler.  The handler gets control first,
>and can decide whether to unwind and handle the exception, to pass control up 
>to the next handler, or to continue execution of the code that raised (threw)
>the exception.  

That is usually referred to as "resumeable exceptions", since you can
elect to resume from the point of the exception as if nothing had
happend. C++ exceptions are non-resumable; you always unwind up to the
location of the exception handler.

Whether to have resumeable or non-resumeable exceptions was debated
EXTENSIVELY -- for about two years -- before it was settled. A vocal
minority wanted resumeable exceptions. The clinching argument came from
a presentation by Jim Mitchell, long a proponent of resumeable exceptions.
He and his colleagues found over time that resumeable exceptions hardly
ever were useful; code that had used them tended over time to be modified
so as not to use the resume option. He came to the point of reversing
his stance.

In addition, allowing exceptions to be resumed forces a lot of overhead on
all programs that use exceptions, even if they do not want to resume them. Non-
resumeable exceptions do not require much overhead. Furthermore, you can
simulate resumeable exceptions (although not as conveniently) if you want
the capability. It's more work for the programmer, but only programs that
want to resume exceptions have to pay the price.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]