Mike, if an article doesn't appear, please don't just post it
again. Send a query to the moderator's contact address, as
explained in the newsgroup FAQ. (I'm forwarding this message
to the contact address.)

I didn't see the original version of this article. Fergus, did
you see it?

---
Steve Clamage

>From: "William M. Miller" <wmm@fastdial.net>
>To: <std-c++@ncar.UCAR.EDU>
>Subject: Fw: Signals and exceptions? (was: Exception blues...)
>Date: Tue, 7 Sep 1999 07:55:34 -0400
>Content-Transfer-Encoding: 7bit
>X-Priority: 3
>X-MSMail-Priority: Normal
>X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
>
>Hi.  I posted this on Saturday but it hasn't appeared in comp.std.c++,
>so I thought I should send it again directly in case it got lost.
>
>-- wmm
>----- Original Message -----
>From: William M. Miller <wmm@fastdial.net>
>Newsgroups: comp.std.c++
>Sent: Saturday, September 04, 1999 10:34 AM
>Subject: Re: Signals and exceptions? (was: Exception blues...)
>
>
>> blargg <postmast.root.admi.gov@iname.com> wrote in message
>> news:user-0309990218320001@aus-as3-177.io.com...
>> >
>> > In article <7qjr3v$vfr$1@nnrp1.deja.com>, wmm@fastdial.net wrote:
>> >
>> > > 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?
>>
>> [explantory code sample elided]
>>
>> This is a reasonable approach.  However, it's a lot of mechanism to
>> provide something that could be nearly as simple as "throw" and
>> "catch."  Also, no one has proposed anything like this for the standard
>> library, so it's still a matter of ad hoc, roll-your-own coding.
>>
>> > > 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.
>>
>> There's a sizable body of experience demonstrating that they _do_
>> merge, very effectively and conveniently.
>>
>> > > 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.
>>
>> Actually, this isn't the minimalist position.  The true minimalist
>approach
>> would have been simply to require longjmp to do destructor invocation
>> during stack unwinding and not make any changes to the language at
>> all.
>>
>> This is my reaction to suggestions that resumption can be provided by
>> library code: it's true, but it's equally true of terminating exceptions
>as
>> well.  I think there were valid reasons for adding terminating exceptions
>> to the language, and I believe they apply just as much to resumable
>> exceptions.
>>
>> > I guess my question is this: What aspect of resumable exceptions is
>> > impractical to implement in ISO C++ as a library?
>>
>> You could as well ask, "What aspect of virtual functions is impractical
>> to implement in ISO C using tables of function pointers?"  The
>> answer is the same: Nothing.  It's all a matter of convenience,
>> simplicity, ease-of-use, robustness, readability, maintainability,
>> etc.
>>
>> > > 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.
>>
>> This seems like assuming the conclusion.  The point of citing this
>> laundry list was to highlight the fact that all of these things were
>> handled with the same mechanism -- experience, not speculation --
>> and that it was very convenient.  Programmers could deal with all
>> these kinds of things using exactly the same language construct;
>> they didn't need to learn a half-dozen different mechanisms.  All
>> they needed to know was the name of the condition and a bit of
>> its associated semantics.  Why complicate programmers' lives?
>> They have enough (too much) to learn already.
>>
>> > 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.
>>
>> "Inappropriate" is in the eye of the beholder.  The structural
>similarities
>> and the ease-of-use of a single mechanism were the overriding
>> criteria, in my experience.
>>
>> > 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 may be misunderstanding your point, but this seems like a strength
>> rather than a weakness to me.  In the first example, the exception
>> handling code (in "handler") is textually separated from the operations
>> (the call to "lib()") with which it is associated, which is a maintenance
>> problem -- "out of sight, out of mind."  I think it's an advantage of the
>> current exception handling specification that the handlers appear
>> immediately after the try-block rather than in separate functions.
>>
>> > 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).
>>
>> Which could have been addressed in either of two ways:
>>
>> 1) Add nested functions to the language.
>>
>> 2) Restrict handler code in the same way that member functions of
>> local classes are restricted (no access to auto variables in
>> lexically-containing scopes).
>>
>> > *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.
>>
>> Well, maybe; my expectation would be that, given the resumption
>> mechanism in the language, the customization would be pretty much
>> done by providing different derived classes based on an enhanced
>> std::exception.
>>
>> > I think synchronous exceptions have a much wider audience than
>> > resumable exceptions, and affect cross-library compatibility to a much
>> > greater extent.
>>
>> I agree that library exceptions would likely be mostly terminating.
>> However, there are lots of cases where the semantics would lend
>> themselves to, "Whoops, you didn't give me enough/correct
>> information for this operation -- if you want me to continue, you'll
>> have to tell me more!"  And remember that the handler of a
>> resumable exception doesn't have to return.  Given that the
>> library will be throwing exceptions anyway, I would expect a fair
>> amount of pressure from users to make those exceptions
>> resumable if a return might remotely make sense.
>>
>> > > 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.
>>
>> Would you have been happy with a C++-aware setjmp/longjmp?  (This
>> is a real question, not a rhetorical jab.)
>>
>> > Thanks again for sharing your thoughts.
>>
>> Thanks for asking. :-)
>>
>> > Is anyone else interested in these issues?
>>
>> Probably not.  It's awfully theoretical -- I think there's a better chance
>> of a doomsday asteroid before Y2K than that resumable exceptions
>> will ever be part of C++.
>> --
>> William M. Miller, wmm@fastdial.net, wmm@setech.com
>> Software Emancipation Technology, Inc.,    +1 (781) 359-3335
>> 15 Third Ave., Burlington, MA 01803   FAX: +1 (508) 256-0073
>>         http://www.setech.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              ]