blargg <postmast.root.admi.gov@iname.com> wonders:
> Is anyone else interested in these issues?

I've been following the discussion.  And here's a point I'd like to see
the advocates of resumable exceptions address:

One of the things I like about the terminating model is that when I throw
an exception, I know it isn't coming back.  I can write:

void Elevator::MoveTo( int floor )
  {
   if ( floor == 13 )
      throw NoThirteenthFloor();
   ...
  }

And I don't have to consider, "what do I do when some idiot resumes
the exception?"

While exceptional situations allow for resumption, some just don't.
And I think that decision belongs at the throw-point, not up in each
catch block.

                                                --Lisa Lippincott
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <4mmz3.436$PF3.38494@ndnws01.ne.mediaone.net>,
  "Dave Abrahams" <abrahams@mediaone.net> wrote:
>
> In article <7qgius$h8k$1@nnrp1.deja.com> , wmm@fastdial.net  wrote:
>
> >  try {
> >      write_report();
> >  }
> >  catch (endpage<cout>) {
> >      write_page_footer();
> >      write_page_header();
> >      continue;
> >  }
> >
> > The idea here is that write_report() might have dozens of different
> > places at which output is done.  Rather than checking for the end of
> > page processing at each, each one simply does its writing and when
> > the end of the page is reached, the endpage exception is thrown.
The
> > handler writes the footer of the current page and the header of the
> > next page and simply returns, to allow the output that would have
> > overflowed the current page to be written at the top of the next
page.
>
> This example seems like a natural situation in which to use a
function, and
> doesn't at all look like an error condition. Why do you want it to
look like
> an exception?

Because 1) it's structurally the same -- the situation needing
attention is detected someplace but the smarts for attending to it
are someplace further up the call stack; 2) it's better to have a
single idiom for handling situations with that structure, especially
an idiom that is supported by the language itself rather than
created ad hoc; 3) it's better to have the handler code right by the
operations it's associated with rather than in a separate, perhaps
hard-to-find function; 4) it's less error-prone -- the handler
associated with this call goes away when its try block is
exited, but you have to supply your own discipline (perhaps using
an auto_ptr-like class) to ensure correct pushing and popping of
callback-style handlers.

There's no reason exceptions should be restricted to handling errors;
it's only because of termination semantics that that's all they're
good for in C++.
--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Lisa Lippincott <lisa_lippincott@advisories.com> writes:

> One of the things I like about the terminating model is that when I throw
> an exception, I know it isn't coming back.  I can write:
>
> void Elevator::MoveTo( int floor )
>   {
>    if ( floor == 13 )
>       throw NoThirteenthFloor();
>    ...
>   }
>
> And I don't have to consider, "what do I do when some idiot resumes
> the exception?"
>
> While exceptional situations allow for resumption, some just don't.
> And I think that decision belongs at the throw-point, not up in each
> catch block.

What this suggests is that guaranteed-terminating and potentially-
resuming "exceptions" are very different beasts, and that it's
misleading for us to call them by the same name.  If both are believed
to be useful, perhaps there should be two different language
mechanisms.

(Not that I'm suggesting that resuming exceptions be retrofitted into
C++.  This is idle speculation that may or may not be relevant when we
think about the next language.)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <ObRz3.734$m84.20924@burlma1-snr2> , Barry Margolin
<barmar@bbnplanet.com>  wrote:

> In article <4mmz3.436$PF3.38494@ndnws01.ne.mediaone.net>,
> Dave Abrahams <abrahams@mediaone.net> wrote:
>>This example seems like a natural situation in which to use a function, and
>>doesn't at all look like an error condition. Why do you want it to look like
>>an exception?
>
> For the same reason that exceptions are better than set_new_handler().

This strikes me a bit like saying we should use virtual functions for
typedefs. They're utterly different beasts, as Lisa Lippincott astutely
points out. Exceptions say "I'm never coming back", and set_new_handler()
says "fix things up so I can continue". The flip side of her question came
to me yesterday: "suppose nobody catches your page-boundary exception?".

The _only_ difference I can see in expressiveness between the resumable
exception proposal and the mechanisms already supported by the language is
that local variables at the handler site are not immediately available in
the same way. I tend to think that over-reliance on this feature would
result in unmaintainable programs eventually as functions became stretched
out to include handlers, but of course, the handlers could always be broken
out into separate functions... ;)

So far it looks to me like the mechanism Blargg describes is a perfectly
good (and more-efficient) one for doing the sort of thing being proposed,
and that mixing it up with the language support for exceptions would be a
disaster.

-Dave
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <030919991310034553%lisa_lippincott@advisories.com>,
  Lisa Lippincott <lisa_lippincott@advisories.com> wrote:
> blargg <postmast.root.admi.gov@iname.com> wonders:
> > Is anyone else interested in these issues?
>
> I've been following the discussion.  And here's a point I'd like to
see
> the advocates of resumable exceptions address:
>
> One of the things I like about the terminating model is that when I
throw
> an exception, I know it isn't coming back.  I can write:
>
> void Elevator::MoveTo( int floor )
>   {
>    if ( floor == 13 )
>       throw NoThirteenthFloor();
>    ...
>   }
>
> And I don't have to consider, "what do I do when some idiot resumes
> the exception?"
>
> While exceptional situations allow for resumption, some just don't.
> And I think that decision belongs at the throw-point, not up in each
> catch block.

Yes, of course.  It was never intended that all exceptions be
resumable, only the ones where it makes sense.  An attempt to return
from a handler invoked for a non-resumable exception would either
throw a "Bad_Exception_Return" exception (non-resumable, of course)
or call terminate() -- the detailed design was never completed, but
something along those lines.

The precise mechanism for specifying whether a given throw was
resumable or not was never nailed down, but some possibilities
include:

1) Distinguished resumable and nonresumable exception classes in the
standard library.

2) throw and throw_resumable keywords.

3) Make "throw" a standard function instead of a keyword, with one
parameter indicating whether a return was allowed.

--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 06 Sep 99 16:59:04 GMT, Lisa Lippincott
<lisa_lippincott@advisories.com> wrote:

>I've been following the discussion.  And here's a point I'd like to see
>the advocates of resumable exceptions address:
>
>One of the things I like about the terminating model is that when I throw
>an exception, I know it isn't coming back.  I can write:
>
>void Elevator::MoveTo( int floor )
>  {
>   if ( floor == 13 )
>      throw NoThirteenthFloor();
>   ...
>  }
>
>And I don't have to consider, "what do I do when some idiot resumes
>the exception?"

If that's a concern, just quit.

  if ( floor == 13 )
    throw NoThirteenthFloo();
  if ( floor == 13 )
    // Use your favorite exit() mechanism here.
    // Anything but throw will do...

If you write a library, for instance, and are afraid that your
callers will resume, you can guard your exported interface with
a try(), and then either throw or return.

If clients (stupidly) resumes exceptions they shouldn't, then
they have a bug. It doesn't matter if you throw an exception
or simply return back.


---------------------------------------------
Ziv Caspi
zivca@netvision.net.il


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <uMUA3.2141$PF3.137295@ndnws01.ne.mediaone.net>,
  "Dave Abrahams" <abrahams@mediaone.net> wrote:
> In article <ObRz3.734$m84.20924@burlma1-snr2> , Barry Margolin
> <barmar@bbnplanet.com>  wrote:
>
> > In article <4mmz3.436$PF3.38494@ndnws01.ne.mediaone.net>,
> > Dave Abrahams <abrahams@mediaone.net> wrote:
> >>This example seems like a natural situation in which to use a function, and
> >>doesn't at all look like an error condition. Why do you want it to look like
> >>an exception?
> >
> > For the same reason that exceptions are better than set_new_handler().
>
> This strikes me a bit like saying we should use virtual functions for
> typedefs. They're utterly different beasts, as Lisa Lippincott astutely
> points out. Exceptions say "I'm never coming back", and set_new_handler()
> says "fix things up so I can continue".

There are more similarities than differences.  Both are ways to
handle the common situation in which an exceptional condition is
detected in code that is not capable of applying the appropriate
recovery strategy, but where such recovery is possible somewhere
in the calling context.  The _only_ difference is the exact details
of the recovery.  In one case it's "attempt a repair and try again,"
in the other it's "abort the operation and get to a known good
state."

However, the _structure_ is the same, and I don't see the advantage
of requiring two entirely separate mechanisms depending on the
details of the recovery to be applied.  It complicates the
specification of the library interface, and it complicates the user
code.

> The flip side of her question came
> to me yesterday: "suppose nobody catches your page-boundary exception?".

The default action for an unhandled endpage exception would be
simply to return, the result being that you just print across
the perforation with no pagination.  For other exceptions, the
appropriate default action might be to call terminate(), or some
other action.  Each kind of exception would define its own
default recovery.

> The _only_ difference I can see in expressiveness between the resumable
> exception proposal and the mechanisms already supported by the language is
> that local variables at the handler site are not immediately available in
> the same way. I tend to think that over-reliance on this feature would
> result in unmaintainable programs eventually as functions became stretched
> out to include handlers, but of course, the handlers could always be broken
> out into separate functions... ;)

Exactly.  I tend to think that it's better (locality of reference,
"out of sight, out of mind") to have the handler for a condition
in close textual proximity to the operations it's associated with.
If the recovery is extensive or there are lots of exceptions to be
handled at the same point, it might make sense to parcel them out
to separate functions.  That choice would be up to the programmer.

With the callback mechanism for resumption, there is no choice --
even a one-line recovery all by itself has to be in a completely
separate function.

As for the code bloat factor, I don't see that it would be any
worse with resumable exceptions than with terminating exceptions
(which does offer the choice of locality versus modularity, of
course).

> So far it looks to me like the mechanism Blargg describes is a perfectly
> good (and more-efficient) one for doing the sort of thing being proposed,
> and that mixing it up with the language support for exceptions would be a
> disaster.

It is certainly possible to use Blargg's mechanism (I've commented
on it in a posting on Saturday that somehow got lost -- I've sent
it in again via email, so maybe it will show up by the time this
does), just as it's possible to simulate virtual functions by using
explicit tables of function pointers.  I'm quite happy, though, that
virtual functions are part of the language.

I haven't seen anything remotely resembling "disaster" in this
discussion, though.  Certainly it's possible to write spaghetti
threads using resumable exceptions.  I'm a lot more worried about
people getting lost in unintended overload resolution and template
specializations than I would be about people inadvertently creating
problems with resumable exceptions.  Like many C++ features, they
are subject to abuse, but straightforward uses are, well,
straightforward. :-)

--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <user-3008990904290001@aus-as5-130.io.com>,
  postmast.root.admi.gov@iname.com (blargg) wrote:
> In article <7qdv1o$ke4$1@nnrp1.deja.com>, wmm@fastdial.net wrote:
>
> > In article <7qbouc$18lh$1@hardcore.ivn.net>,
> >   "Scott Robert Ladd" <scott@coyotegulch.com> wrote:
> > >
> > > C++ incorporates the full C library, including signal support via
<csignal>.
> > > Since signal is "standard" across several platforms, why didn't
Standard C++
> > > implement exceptions for those signals? Admittedly, it is possible
to trap
> > > signals and convert them to an exception -- but it seems to me
that trapping
> > > "divide by zero" would, at a minimum, be required by a robust
programming
> > > language?
> >
> > This was part of the motivation I had for advocating resumable
> > exceptions back in the early days of the standardization process --
> > resumable exceptions map more closely into asynchronous events and
> > hardware-based interrupts than terminating exceptions.
>
> But exceptions are a synchronous thing, since a particular thread of
code
> deals with them. I don't see how the exception mechanism could be
relevant
> to asynchronous events. Those require a separate mechanism (as far as
I
> can tell). Please say so if you think otherwise.

I think otherwise.  I think it's a definitional thing -- if you view
an exception as a non-local goto, then obviously exceptions are not
suited to asynchronous events, because you'd have no idea what kind
of thing you were aborting.  My view of an exception is more like an
interrupt handler that might, but need not, end with a non-local
goto.  On the other hand, it might fix (or ignore, if it made sense)
the problem and continue the processing exactly where it was
asynchronously interrupted.  In this view, exceptions are perfectly
well-suited for asynchronous events.

> > Unfortunately (from my perspective), the majority of the committee
> > were not persuaded and we ended up with the simpler but less
> > capable version of exceptions we have today.
>
> Less capable isn't necessarily worse. Engineering isn't about putting
all
> possible capability into something, as if its value were based
entirely on
> the number of features.

No argument.  I was using the phrase descriptively, not disparagingly.
The debate over termination vs. resumption was in some degree a
disagreement over whose view of simplicity was more compelling.  I
thought having a single mechanism that encompassed signals,
terminating exceptions, and new_handler-style callbacks was simpler
than having three overlapping mechanisms, especially given that the
callbacks were not supported in any significant way by the standard and
library and had to be invented ad hoc every time someone needed
resumption.  The other group felt that giving exceptions strict
termination semantics was a desirable simplification.  Simplicity
is desirable but must be weighed in a cost-benefit analysis, and that
was the crux of the disagreement.

> I would be interested in your arguments for resumable exception
handling.
> Having just re-read the note in D&E about the arguments for and
against
> resumable exception handling, and why it was ultimately decided
against, I
> would like to hear the your side. What experience do you have with
> resumable exceptions? What were the cases where they were of practical
use
> in non-debugging situations? Could those uses be handled with
functions in
> the style of set_new_handler(), without any serious drawbacks? Do
> resumable exceptions provide some benefits to library authors that
can't
> be easily be remedied in the set_new_handler() style (for example,
> exceptions allow much smoother interoperability between libraries)?

I thought Bjarne did a commendably even-handed presentation of the
respective arguments in D&E; I could elaborate on some of the items
in his list favoring resumption, but I think he mentioned all the
major points I would make.

My own experience in resumable exceptions was on Multics (as cited by
Barry Margolin elsewhere in this thread) and Prime, using PL/I
on-conditions.  I found them to be flexible and convenient, both
for user programming and inside the OS.  They were used for everything
from detection of the end of a page when writing a printout (so you
just wrote a handler that did footers and headers and then printed
willy-nilly without needing to check whether it was time to do a page
eject or not) to handling user control-C interrupts ("Do you really
want to quit?  Type 'yes' or 'no':") to zerodivide and fixedoverflow
to user-defined conditions to page-faults (in the OS).

I never had any significant problems with them, nor do I recall anyone
else I knew having problems.  (I think Bjarne was a being a bit
tongue-in-cheek in his comment about experience with PL/I on-conditions
being used by both sides of the debate.  I don't recall any concrete
negative experience being cited; it was more the case that PL/I was
such joke-fodder that any experience in PL/I was automatically
suspect and discounted.)

It's certainly the case that new_handler-style callbacks can provide
resumption semantics.  However, one of the major reasons for adding
exception handling in the first place was to provide a single
mechanism that would be used compatibly across multiple libraries.
The current exception specification accomplishes that goal for cases
in which termination is the proper response, but provides no support
at all for cases in which resumption is appropriate -- everyone is
stuck reinventing the wheel.

(Apologies if this ends up being largely duplicated -- I wrote a
response yesterday and thought I posted it, but it never showed up,
so I thought I should try again.)
--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qgius$h8k$1@nnrp1.deja.com> , wmm@fastdial.net  wrote:

>  try {
>      write_report();
>  }
>  catch (endpage<cout>) {
>      write_page_footer();
>      write_page_header();
>      continue;
>  }
>
> The idea here is that write_report() might have dozens of different
> places at which output is done.  Rather than checking for the end of
> page processing at each, each one simply does its writing and when
> the end of the page is reached, the endpage exception is thrown.  The
> handler writes the footer of the current page and the header of the
> next page and simply returns, to allow the output that would have
> overflowed the current page to be written at the top of the next page.

This example seems like a natural situation in which to use a function, and
doesn't at all look like an error condition. Why do you want it to look like
an exception?


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <4mmz3.436$PF3.38494@ndnws01.ne.mediaone.net>,
Dave Abrahams <abrahams@mediaone.net> wrote:
>This example seems like a natural situation in which to use a function, and
>doesn't at all look like an error condition. Why do you want it to look like
>an exception?

For the same reason that exceptions are better than set_new_handler().

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qjr3v$vfr$1@nnrp1.deja.com>, wmm@fastdial.net wrote:

> In article <user-3008990904290001@aus-as5-130.io.com>,
>   postmast.root.admi.gov@iname.com (blargg) wrote:
> > In article <7qdv1o$ke4$1@nnrp1.deja.com>, wmm@fastdial.net wrote:
> >
> > > In article <7qbouc$18lh$1@hardcore.ivn.net>,
> > >   "Scott Robert Ladd" <scott@coyotegulch.com> wrote:
> > > >
> > > > C++ incorporates the full C library, including signal support via
> > > > <csignal>. Since signal is "standard" across several platforms, why
> > > > didn't Standard C++ implement exceptions for those signals?
> > > > Admittedly, it is possible to trap signals and convert them to an
> > > > exception -- but it seems to me that trapping "divide by zero"
> > > > would, at a minimum, be required by a robust programming
> > > > language?
> > >
> > > This was part of the motivation I had for advocating resumable
> > > exceptions back in the early days of the standardization process --
> > > resumable exceptions map more closely into asynchronous events and
> > > hardware-based interrupts than terminating exceptions.
> >
> > But exceptions are a synchronous thing, since a particular thread of
> > code deals with them. I don't see how the exception mechanism could be
> > relevant to asynchronous events. Those require a separate mechanism (as
> > far as I can tell). Please say so if you think otherwise.
>
> I think otherwise.  I think it's a definitional thing -- if you view
> an exception as a non-local goto, then obviously exceptions are not
> suited to asynchronous events, because you'd have no idea what kind
> of thing you were aborting.

Right. And that's exactly what I view excptions as - a non-local goto that
is can be optionally stopped along the way "up the stack" in catch blocks,
by the type of object thrown. The utility is that it is exactly that - a
non-local goto (with the added benefit of a typed object, but that isn't
essential as far as what the language provides). See, I'm interested in
the language itself only providing what libraries can't provide
(reasonably). With exceptions, many error handling (and other patterns)
can be implemented.

Now, what this means is simply that this form of exceptions I think a
compiler needs to implement. What you're proposing, I think can be
provided fairly elegantly within the framework given in the language.

> My view of an exception is more like an
> interrupt handler that might, but need not, end with a non-local
> goto.

Why not use exceptions with functions to provide this composite behavior?
I'm thinking along the lines of a registry of handlers, where the handler
can either handle and re-run the condition, or throw an exception. The
very essence of the idea could be distilled to this:

    struct Unhandled { }; // exception class

    class Handler {
        Handler* const prev;
    public:
        Handler();
        virtual void handle() {
            throw Unhandled();
        }
    };

    Handler* handler;

    Handler default_handler; // will set handler

    Handler::Handler() : prev( handler ) { handler = this; }

    Handler::~Handler() { handler = prev; }

    void lib() {
        // ...
        if ( some_condition )
            handler->handle();
    }

    void user1() {
        struct : Handler {
            // any local shared variables
            void handle() {
                // ...
                if ( cant_handle )
                    Handler::handle(); // throws exception
            }
        } handler;

        // handler.var // can set shared variable

        lib();
    }

Here, the user provides an explicit handler for the condition.

A user could also catch the exception (without any retry ability):

    void user2() {
        try {
            Handler handler; // use default handler that throws exception
            lib();
        }
        catch ( Unhandled ) {
            // lib encountered some_condition
        }
    }


> On the other hand, it might fix (or ignore, if it made sense)
> the problem and continue the processing exactly where it was
> asynchronously interrupted.  In this view, exceptions are perfectly
> well-suited for asynchronous events.

Or whatever you want to call them (why fight over which model gets to be
called "exception handling"?). Yes, this is a reasonable model for
handling asynchronous events like this. I just don't think it should be
mixed with handling of synchronous exceptions (the kind that can only be
generated at *well-defined* points in the code, and only affect the
*current thread* of execution).

> > > Unfortunately (from my perspective), the majority of the committee
> > > were not persuaded and we ended up with the simpler but less
> > > capable version of exceptions we have today.
> >
> > Less capable isn't necessarily worse. Engineering isn't about putting
> > all possible capability into something, as if its value were based
> > entirely on the number of features.
>
> No argument.  I was using the phrase descriptively, not disparagingly.

OK.

> The debate over termination vs. resumption was in some degree a
> disagreement over whose view of simplicity was more compelling.

I wouldn't look at it like one model is flawed and the other isn't. They
seem to serve different purposes, so should be kept separate. However,
lacking experience with resumable exceptions, I can't really say strongly
that they are that different or not.

> I
> thought having a single mechanism that encompassed signals,
> terminating exceptions, and new_handler-style callbacks was simpler
> than having three overlapping mechanisms, especially given that the
> callbacks were not supported in any significant way by the standard and
> library and had to be invented ad hoc every time someone needed
> resumption.

Sure, and having one model for all member functions (all virtual) would be
simpler too, but then everyone would be paying for something they may not
need. I think these things need to be kept separate, if they are separate
concepts. If you try to merge things that don't merge, you'll likely end
up is killing off both of them.

> The other group felt that giving exceptions strict
> termination semantics was a desirable simplification.

I see their semantics as more than just a simplification. The concept is
simply a non-local goto that can be terminated. In essence, this is all
that is absolutely necessary to be implemented in the language (but would
have been a bit inconvenient):

    void f() {
        throw;
    }

    void g() {
        try {
            X x; // X is destructed when it goes out of scope
            f();
        }
        catch {
        }
    }

Everything else can be built from there using this base language
mechanism. I think this is the essence of exceptions. This hasn't been
simplified at all - it *is* how simple the (synchronous) exception
handling mechanism is in C++. To try to mix this paradigm with something
else would be confusing things, I think.

> Simplicity
> is desirable but must be weighed in a cost-benefit analysis, and that
> was the crux of the disagreement.

I guess my question is this: What aspect of resumable exceptions is
impractical to implement in ISO C++ as a library?

[snip]
> I thought Bjarne did a commendably even-handed presentation of the
> respective arguments in D&E; I could elaborate on some of the items
> in his list favoring resumption, but I think he mentioned all the
> major points I would make.
>
> My own experience in resumable exceptions was on Multics (as cited by
> Barry Margolin elsewhere in this thread) and Prime, using PL/I
> on-conditions.  I found them to be flexible and convenient, both
> for user programming and inside the OS.  They were used for everything
> from detection of the end of a page when writing a printout (so you
> just wrote a handler that did footers and headers and then printed
> willy-nilly without needing to check whether it was time to do a page
> eject or not) to handling user control-C interrupts ("Do you really
> want to quit?  Type 'yes' or 'no':") to zerodivide and fixedoverflow
> to user-defined conditions to page-faults (in the OS).

These seem like a few different concepts, each needing its own mechanism
to handle it. For the end-of-page detection, wouldn't an end-of-page
handler be appropriate? For control-C, which is asynchronous, it's likely
that a flag would be set for a normal thread of control to see and use
console I/O to ask the question. Processor-level exceptions call for an
entirely different mechanism too. I don't think it would be appropriate to
try to mix these.

The on condition seems like a way to blur function boundaries. For example, this

    void lib() {
        // ...
        if ( some_condition )
            handler();
    }

    void handler() {
        // ...
    }

    void user() {
        lib();
    }

Becomes this:

    void user() {
        lib();
        on condition ( whatever ) { // void handler()
            // ...
        }
    }

I seem to remember Bjarne also commenting that this would require
activation records, but since nothing else in the language took advantage
of them, much of their power would go untapped (think nested functions for
one).

> I never had any significant problems with them, nor do I recall anyone
> else I knew having problems.  (I think Bjarne was a being a bit
> tongue-in-cheek in his comment about experience with PL/I on-conditions
> being used by both sides of the debate.

hehe

> I don't recall any concrete
> negative experience being cited; it was more the case that PL/I was
> such joke-fodder that any experience in PL/I was automatically
> suspect and discounted.)
>
> It's certainly the case that new_handler-style callbacks can provide
> resumption semantics.  However, one of the major reasons for adding
> exception handling in the first place was to provide a single
> mechanism that would be used compatibly across multiple libraries.

OK. It also provided some essential mechanisms that no library could
reasonably provide (well, they could, but not without some significant
inefficiency - I wrote a exception library that could throw and catch
arbitrary types, before my compiler supported them).

*However*, in the case of resumption, I would imagine that they wouldn't
be used *across* libraries, but between the library and users. In this
case, they would likely be stylized a bit for the particular library
anyway. I think synchronous exceptions have a much wider audience than
resumable exceptions, and affect cross-library compatibility to a much
greater extent.

> The current exception specification accomplishes that goal for cases
> in which termination is the proper response, but provides no support
> at all for cases in which resumption is appropriate -- everyone is
> stuck reinventing the wheel.

At least they can (reasonably). All I want C++ to do is provide me with
the tools to provide clients with good solutions. As long as what I need
to do can be done with a library I write in the language, I'm happy.

Thanks again for sharing your thoughts. I'd be interested in continuing
this into much more depth, either here or in private.

Is anyone else interested in these issues?


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 31 Aug 99 05:25:16 GMT, postmast.root.admi.gov@iname.com (blargg)
wrote:
[...]
>What experience do you have with
>resumable exceptions? What were the cases where they were of practical use
>in non-debugging situations? Could those uses be handled with functions in
>the style of set_new_handler(), without any serious drawbacks? Do
>resumable exceptions provide some benefits to library authors that can't
>be easily be remedied in the set_new_handler() style (for example,
>exceptions allow much smoother interoperability between libraries)?

Resumable exceptions are used, for example, by NT. They take care
of things like growing the stack and handling copy-on-write.

The set_new_handler() style requires that the throw mechanism supply
an interface to override it. Resumable exceptions are more capable in
that you can (in a library-transparent way) add a global handler that
automatically handles exceptions (such as insufficient resources) and
resumes.

---------------------------------------------
Ziv Caspi
zivca@netvision.net.il


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <user-3008990904290001@aus-as5-130.io.com>,
  postmast.root.admi.gov@iname.com (blargg) wrote:
> In article <7qdv1o$ke4$1@nnrp1.deja.com>, wmm@fastdial.net wrote:
>
> > In article <7qbouc$18lh$1@hardcore.ivn.net>,
> >   "Scott Robert Ladd" <scott@coyotegulch.com> wrote:
> > >
> > > C++ incorporates the full C library, including signal support via
<csignal>.
> > > Since signal is "standard" across several platforms, why didn't
Standard C++
> > > implement exceptions for those signals? Admittedly, it is possible
to trap
> > > signals and convert them to an exception -- but it seems to me
that trapping
> > > "divide by zero" would, at a minimum, be required by a robust
programming
> > > language?
> >
> > This was part of the motivation I had for advocating resumable
> > exceptions back in the early days of the standardization process --
> > resumable exceptions map more closely into asynchronous events and
> > hardware-based interrupts than terminating exceptions.
>
> But exceptions are a synchronous thing, since a particular thread of
code
> deals with them. I don't see how the exception mechanism could be
relevant
> to asynchronous events. Those require a separate mechanism (as far as
I
> can tell). Please say so if you think otherwise.

I think otherwise.  I've never understood this distinction.  With
resumption, an asynchronous event is handled and then the interrupted
code continues.  As Barry Margolin pointed out in another message in
this thread, this mechanism (PL/I on-conditions) was used throughout
Multics for all kinds of asynchronous events and worked well.

I think the difference in viewpoint is that the termination proponents
think of exceptions as essentially a non-local goto, while I see them
as essentially interrupt handlers that might end with a non-local goto
or might fix (or, if appropriate, ignore) the problem and continue.

> > Unfortunately (from my perspective), the majority of the committee
> > were not persuaded and we ended up with the simpler but less
> > capable version of exceptions we have today.
>
> Less capable isn't necessarily worse. Engineering isn't about putting
all
> possible capability into something, as if its value were based
entirely on
> the number of features.

I have no argument with this position.  I was using "less capable"
descriptively, not disparagingly.  Simplicity is a very significant
consideration; complexity is only justified if the benefits outweigh
the cost.  The discussion over resumption versus termination was
mostly a difference of opinion as to where to draw that line.

> I would be interested in your arguments for resumable exception
handling.
> Having just re-read the note in D&E about the arguments for and
against
> resumable exception handling, and why it was ultimately decided
against, I
> would like to hear the your side. What experience do you have with
> resumable exceptions? What were the cases where they were of practical
use
> in non-debugging situations? Could those uses be handled with
functions in
> the style of set_new_handler(), without any serious drawbacks? Do
> resumable exceptions provide some benefits to library authors that
can't
> be easily be remedied in the set_new_handler() style (for example,
> exceptions allow much smoother interoperability between libraries)?

I think Bjarne did a commendably even-handed presentation of the
issues in his writeup in D&E.  The examples of resumption he cited
(memory exhaustion, divide-by-zero, empty floppy drive) were the
principal ones I used in my papers, and the list of arguments he
gave on page 391 are pretty much the ones I advanced (except for the
OS/2 one, which was Martin O'Riordan's).  Unfortunately I wasn't at
the extensions meeting in Palo Alto with the presentation from
Jim Mitchell, because by that time I had decided that the battle
was lost and there were some interesting questions being discussed in
the core language group at the same time.  I wish now I had gone to
hear the data he presented.

In any case, my experience with resumable exceptions was primarily on
Multics and Prime, using PL/I on-conditions.  (I think Bjarne was
being a little tongue-in-cheek in his comment on page 392, "Experiences
with PL/I's ON-conditions were mentioned as arguments both for and
against resumption."  I don't recall anyone actually citing any
negative experience with on-conditions; since PL/I is commonly used as
joke-fodder, the fact that the experience came from PL/I was taken as
sufficient grounds to impeach its credibility.)

As an example of the typical kind of thing that was done, let me
translate a common idiom into pseudo-C++ with a hypothetical
continuation capability:

 try {
     write_report();
 }
 catch (endpage<cout>) {
     write_page_footer();
     write_page_header();
     continue;
 }

The idea here is that write_report() might have dozens of different
places at which output is done.  Rather than checking for the end of
page processing at each, each one simply does its writing and when
the end of the page is reached, the endpage exception is thrown.  The
handler writes the footer of the current page and the header of the
next page and simply returns, to allow the output that would have
overflowed the current page to be written at the top of the next page.

This same idiom worked for all sorts of things, from handling the user
hitting control-C to interrupt the program ("Do you really want to
quit?  Type yes or no:") to division by zero and integer overflow.  It
was very handy and I never ran into any significant problems with it,
nor heard of others doing so.

Of course the "set_new_handler" approach can be used in these kinds of
situations (at least for software-detected conditions).  My argument
there was in favor of simplicity -- we have three parallel mechanisms
for handling errors: signals, exceptions, and callbacks.  Furthermore,
the callback mechanism is completely roll-your-own, with no support
from the language or the library.  One of the motivations for having
exceptions in the language was to provide a single standard mechanism
so there wouldn't be a proliferation of competing and incompatible
error-handling schemes in different libraries, and it does that for
issues that can be handled by a non-local goto.  It does nothing for
cases that are most naturally or efficiently handled by a resumption
model; we're left with ad hoc solutions for those kinds of problems.
--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qbsda$c11$1@engnews1.eng.sun.com>,
Steve Clamage <clamage@eng.sun.com> wrote:
>Exceptions are synchronous, generated only from specific C++ source-
>code constructs.  (The compiler has enough information to ensure
>synhcronous behavior easily.) It might be extremely difficult or
>even impossible for an implementation to apply exception semantics
>directly to an asynchronous signal reliably and automatically.

Somehow we managed to deal with this issue 20 years ago in Multics (OS
signals were handled using PL/I's ON statement), and in the 80's
MIT/Symbolics/LMI Lisp Machines handled asynchronous signals using
HANDLER-CASE and HANDLER-BIND (which became CONDITION-CASE and
CONDITION-BIND in Common Lisp).

I believe that the main solution is that operations that can't stand to be
interrupted asynchronously would block interrupts.  But perhaps this means
that these translations have to be relegated to the OS standards, rather
than the language standards, unless you want to start adding functions for
masking interrupts to the language.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qdv1o$ke4$1@nnrp1.deja.com>, wmm@fastdial.net wrote:

> In article <7qbouc$18lh$1@hardcore.ivn.net>,
>   "Scott Robert Ladd" <scott@coyotegulch.com> wrote:
> >
> > C++ incorporates the full C library, including signal support via <csignal>.
> > Since signal is "standard" across several platforms, why didn't Standard C++
> > implement exceptions for those signals? Admittedly, it is possible to trap
> > signals and convert them to an exception -- but it seems to me that trapping
> > "divide by zero" would, at a minimum, be required by a robust programming
> > language?
>
> This was part of the motivation I had for advocating resumable
> exceptions back in the early days of the standardization process --
> resumable exceptions map more closely into asynchronous events and
> hardware-based interrupts than terminating exceptions.

But exceptions are a synchronous thing, since a particular thread of code
deals with them. I don't see how the exception mechanism could be relevant
to asynchronous events. Those require a separate mechanism (as far as I
can tell). Please say so if you think otherwise.

> Unfortunately (from my perspective), the majority of the committee
> were not persuaded and we ended up with the simpler but less
> capable version of exceptions we have today.

Less capable isn't necessarily worse. Engineering isn't about putting all
possible capability into something, as if its value were based entirely on
the number of features.

I would be interested in your arguments for resumable exception handling.
Having just re-read the note in D&E about the arguments for and against
resumable exception handling, and why it was ultimately decided against, I
would like to hear the your side. What experience do you have with
resumable exceptions? What were the cases where they were of practical use
in non-debugging situations? Could those uses be handled with functions in
the style of set_new_handler(), without any serious drawbacks? Do
resumable exceptions provide some benefits to library authors that can't
be easily be remedied in the set_new_handler() style (for example,
exceptions allow much smoother interoperability between libraries)?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage <clamage@eng.sun.com> wrote in message
news:7qbsda$c11$1@engnews1.eng.sun.com...
[snip]
> Signals are inherited from C. In general, a signal can be
> asynchronous. A signal might be generated from an event not
> directly related to program code. Or consider a separate
> floating-point unit that generates a signal while the main
> processing is working on something else and isn't ready to
> use the results of the FP calculation.
>

So why can't processor restore it's pipeline to the state where FP command
was sent to the FP processor? How is it more difficult than the general case
of speculative execution?

Gene Bushuyev
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <066e05801181e89CPIMSSMTPE01@msn.com>, "Gene Bushuyev"
<gbush@my-deja.com> wrote:

> Steve Clamage <clamage@eng.sun.com> wrote in message
> news:7qbsda$c11$1@engnews1.eng.sun.com...
> [snip]
> > Signals are inherited from C. In general, a signal can be
> > asynchronous. A signal might be generated from an event not
> > directly related to program code. Or consider a separate
> > floating-point unit that generates a signal while the main
> > processing is working on something else and isn't ready to
> > use the results of the FP calculation.
> >
>
> So why can't processor restore it's pipeline to the state where FP command
> was sent to the FP processor?

That would require running time backwards (not possible yet) or storing
the processor state before each FP call. If FP operations could be
pipelined, this would require having multiple processor state save areas
for each FP operation. Also, if the processor is to provide a sequential
model of execution to the program (a good thing in general), it would have
to stall any instructions that modified external state (memory) until all
previous FP operations had gotten past the point they could cause a
processor exception.

Precise processor exceptions can be espensive on pipelined architectures.

> How is it more difficult than the general case
> of speculative execution?

The question should be, what benefits do precise exceptions provide to
most code? Where the benefits are needed, often the code can instead
explicitly check for conditions that could cause an exception, possibly
even being more efficient than enabling precise exceptions (if the
processor is even capable of it).
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Robert Ladd wrote:
>
> C++ incorporates the full C library, including signal support via <csignal>.
> Since signal is "standard" across several platforms, why didn't Standard C++
> implement exceptions for those signals? Admittedly, it is possible to trap
> signals and convert them to an exception -- but it seems to me that trapping
> "divide by zero" would, at a minimum, be required by a robust programming
> language?
>
> Is this a philosophical demarcation issue, as in: "Exceptions occur in
> program code; signals occur in the operating system?"

What if a signal happens in destructor code?
Note that signals do not just occur in cases like division
by zero, but also in various really asynchronous cases,
like SIGPIPE.

Also, signals are not only used for error cases.
For example, Unix systems can cause an exception (SIGCHILD)
if a child process terminates. You certainly do not want
an exception thrown at this event. Another signal is
SIGWINCH, which is sent if the xterm size changes.
Again, I doubt anyone would like an exception to be
thrown here.
And the ultimate non-error: SIGIO - I/O now possible.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

C++ incorporates the full C library, including signal support via <csignal>.
Since signal is "standard" across several platforms, why didn't Standard C++
implement exceptions for those signals? Admittedly, it is possible to trap
signals and convert them to an exception -- but it seems to me that trapping
"divide by zero" would, at a minimum, be required by a robust programming
language?

Is this a philosophical demarcation issue, as in: "Exceptions occur in
program code; signals occur in the operating system?"

--
  *     Scott Robert Ladd
  *
  *     Coyote Gulch Productions - http://www.coyotegulch.com
  *     GameLore - http://www.gamelore.com





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Scott Robert Ladd" <scott@coyotegulch.com> writes:

>C++ incorporates the full C library, including signal support via <csignal>.
>Since signal is "standard" across several platforms, why didn't Standard C++
>implement exceptions for those signals? Admittedly, it is possible to trap
>signals and convert them to an exception -- but it seems to me that trapping
>"divide by zero" would, at a minimum, be required by a robust programming
>language?

>Is this a philosophical demarcation issue, as in: "Exceptions occur in
>program code; signals occur in the operating system?"

Signals are inherited from C. In general, a signal can be
asynchronous. A signal might be generated from an event not
directly related to program code. Or consider a separate
floating-point unit that generates a signal while the main
processing is working on something else and isn't ready to
use the results of the FP calculation.

Because signals are asynchronous, the language definition limits
severly the sort of processing that can be done in a signal
handler. About all you can do portably is set a global flag.

Exceptions are synchronous, generated only from specific C++ source-
code constructs.  (The compiler has enough information to ensure
synhcronous behavior easily.) It might be extremely difficult or
even impossible for an implementation to apply exception semantics
directly to an asynchronous signal reliably and automatically.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qbouc$18lh$1@hardcore.ivn.net>,
  "Scott Robert Ladd" <scott@coyotegulch.com> wrote:
>
> C++ incorporates the full C library, including signal support via <csignal>.
> Since signal is "standard" across several platforms, why didn't Standard C++
> implement exceptions for those signals? Admittedly, it is possible to trap
> signals and convert them to an exception -- but it seems to me that trapping
> "divide by zero" would, at a minimum, be required by a robust programming
> language?

This was part of the motivation I had for advocating resumable
exceptions back in the early days of the standardization process --
resumable exceptions map more closely into asynchronous events and
hardware-based interrupts than terminating exceptions.
Unfortunately (from my perspective), the majority of the committee
were not persuaded and we ended up with the simpler but less
capable version of exceptions we have today.
--
William M. Miller, wmm@fastdial.net
Software Emancipation Technology (www.setech.com)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Robert Ladd wrote:
>
> C++ incorporates the full C library, including signal support via <csignal>.
> Since signal is "standard" across several platforms, why didn't Standard C++
> implement exceptions for those signals? Admittedly, it is possible to trap
> signals and convert them to an exception -- but it seems to me that trapping
> "divide by zero" would, at a minimum, be required by a robust programming
> language?
>
> Is this a philosophical demarcation issue, as in: "Exceptions occur in
> program code; signals occur in the operating system?"

I think that one purpose is to avoid breaking code that expects to
handle the signal, and not to catch the exception.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7qbsda$c11$1@engnews1.eng.sun.com>, clamage@eng.sun.com (Steve
Clamage) wrote:

> "Scott Robert Ladd" <scott@coyotegulch.com> writes:
>
> >C++ incorporates the full C library, including signal support via <csignal>.
> >Since signal is "standard" across several platforms, why didn't Standard C++
> >implement exceptions for those signals? Admittedly, it is possible to trap
> >signals and convert them to an exception -- but it seems to me that trapping
> >"divide by zero" would, at a minimum, be required by a robust programming
> >language?
>
> >Is this a philosophical demarcation issue, as in: "Exceptions occur in
> >program code; signals occur in the operating system?"
>
> Signals are inherited from C. In general, a signal can be
> asynchronous. A signal might be generated from an event not
> directly related to program code.

Essentially these exceptions could occur at random with regard to the rest
of the software. If exceptions were actually done like this, they would
make things worse, not better. The entire system wouldn't be robust.
Separate things wouldn't be separate anymore. Chaos would follow.

> Or consider a separate
> floating-point unit that generates a signal while the main
> processing is working on something else and isn't ready to
> use the results of the FP calculation.

Or even a normal floating-point unit that generates "imprecise"
exceptions. On some CPU architectures, requiring processor exceptions (not
to be confused with C++ exceptions) to be raised precisely at the point in
the instruction stream where a floating-point exception occurs incurs a
performance penalty, since this prevents some pipelining (it adds
dependencies between unrelated instructions, reducing parallelism).

> Because signals are asynchronous, the language definition limits
> severly the sort of processing that can be done in a signal
> handler. About all you can do portably is set a global flag.

I don't think you're even guaranteed to be able to make a function call
reliably from a signal handler, let alone invoke exception unwinding.

[snip]

This is discussed in Stroustrup's Design and Evolution of C++ in section
16.7 on page 393. I highly recommend this book.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]