Re: GException notes

[Karl Nelson <kenelson ece ucdavis edu>]

> 
> hm, except for you reversing the meaning of _try() and _catch(), this

(karl hangs head in shame.)

> approach does look far more appealing to me than havoc's.
> however, i don't think using the function pointers as a key is a very
> good idea, this will require incident knowledge about the callees
> implementation on the caller side, which is breaking the abstration
> level to say the least.

Yes, I was just thinking about how to reuse exception handlers which
is a key feature.  Otherwise, all code becomes nothing by error 
handling.

> 
> first, i don't think we should be talking about exceptions here at all
> if we don't consider some setjmp()/longjmp() hackery, because intermediate
> functions aren't affected (properly handled) at all here for calling
> sequences like:
> 
> A() {
>   TRY {
>     B ();
>   }
>   CATCH...
> }
> 
> B () {
>   C ();
>   stuff1 ();
>   D ();
>   stuff2 ();
> }
> 
> C() { THROW (foo); }
> D() { THROW (bar); }
> 
> without setjmp/longjmp constructs, stuff1() and stuf2() will always
> be executed, no matter how hard C() and D() try to THROW things
> around.

Very true, which is why any mechanism must be used thoughout the
kit if at all.  We in the binding business can't use our language
feature exceptions at all for this exact reason.  The Gtk-- 
calling stack and the gtk+ one are interminguled so much that 
any exception emitted from a C++ section just dies in a C section.
Thus any exception system not used throughout is worthless.

> 
> using setjmp/longjmp, we could add enough hackery to the signalling
> core to prematurely abort emissions and return after calling C(),
> so A() could try do some recovery tricks and retry or simply puke
> on the user. but while that would plug the obvious Dtor lack of C closures
> for the signal core, it is not really a viable approach for a generic
> library like GLib which comes with a huge amount of callback facilities,
> each of which would require the same amount of hackery, as well as third
> party code that makes use of glib and calls user code.

In short, no mechanism would ever work properly.  Thus at best an
error system would be best as you propose.

[...> 
> so suppose we are actully talking about some kind of error stack here,
> there's another interesting thing that would be nice to have, but has
> only been slightly touched by havoc's initial proposal:
> type variant errors

Stack is a very bad idea here.  It forces the system to check the
code every time it is used otherwise it will continue to grow unbounded.
A 2 phase system with a current error and handling error would 
be more appropriate.  Also a simple derivable system like described 
perviously would allow exceptions to contain the appropraite data
without forcing them all into string types.

That could even eliminate the try part and just use the catch.

> > It seems to me that adding lots of exception pointers to the end
> > of functions will just make life very hard, especially for connections
> > and backward compatibility.
> 
> not to mention varargs functions which want to report errors, but
> had to break with that convention.

Reuse was the idea, but clearly there are other ways to go about it.

--Karl