exception handling (was Re: expr?(void):(void))

[Guy Harris]

> > The solution we use is to have the _WriteBuf function, instead of
> > returning an indication of error, either print the message and
> > exit itself, or "raise an event" that can be trapped in the user's
> > code (signals or longjumps).  [This wins big.]
> 
> On the whole I think this an excellent idea... but Ray, is it too late
> to convince the people involved *not* to use signals for communications?
> This has long been recognized as a bad idea.  And it's so unnecessary
> in this case, and related ones:  it suffices to say that whenever the
> _WriteBuf function fails, it calls (say) _WBerror with some suitable
> parameters, and the user can substitute his own _WBerror function if he
> doesn't like the default one.  This gets much of the benefit without
> the various problems and unportabilities of signals.

S5 has a "software signals" package; it provides some number of software
signals (this number happens to be the same number as the number of UNIX
signals).  If you call "ssignal", it establishes a handler for the exception
with the specified number.  If you call "gsignal", it calls the exception
handler for the exception with the specified number.  If the handler is
SIG_DFL or SIG_IGN, "gsignal" doesn't call any routine.  If there is a
handler, or if the handler is SIG_IGN, "gsignal" returns 1 (i.e., "there is
an action and it has been taken).  If the handler is SIG_DFL, it returns 0
(i.e., "there is no action so you should supply the default actions").

This provides the same function as the "call _WBerror" scheme does, without
the disadvantage of adding this magic name to the global name space.

This is a fairly straightforward function, so somebody can write it given
the S5 manual page.

It is amusing to note that the S5 manual page for this package clains that
"this facility is used by the Standard C Library to enable users to indicate
the disposition of error conditions..."; this is, like many other claims in
the UNIX documentation, a lie, but it does indicate that they may have
intended that this package be used for this function.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.com (or guy at sun.arpa)