Re: GException notes

[Tim Janik <timj gtk org>]

On 1 Feb 2000, Havoc Pennington wrote:

> Tim Janik <timj@gtk.org> writes:
> > without setjmp/longjmp constructs, stuff1() and stuf2() will always
> > be executed, no matter how hard C() and D() try to THROW things
> > around.
> > while havoc is about to jump up at this point to tell that B() is
> > incredibly wrong coded because it doesn't CATCH after calling C(),
> 
> It _is_ wrong.
> 
> > this is exactly the situation you'll find most often in gtk+ code.

> KISS - errors are for simple stuff, like gdk_pixbuf_new_from_file(),
> GConf, pango_do_whatever_pango_does(). Introducing errors into GTK's
> GUI stuff and signal handlers just makes life hellishly overcomplex by
> requiring you to check errors after _every_ line of GTK code.

havoc, you should make your mind up on whether you want some genuine errno
improvement for *one* level function calls or a flow-control affecting
error handling mechanism.

judging from your other mails the latter seems to be the case, maybe
i was just mislead in the first place by you naming that thinggy "exception".
in any case, what my mail was about, was outlining:

1) you don't get exception-like handling in C without setjmp/longjmp
2) if you don't go with setjmp/longjmp code (which we definitely won't do
   in glib/gtk+ [wink to owen]) but still want to come close to an
   exception handling like scheme, you'll have your callers normally execute
   untill they terminate (we need to, because there's no such thing as a
   closure dtor in C) and thus you have to care about *multiple* errors to
   occour in an callback driven system before you actually get around to
   handle any of them
3) brainstorming of an idea how 2) *could* be implemented, the stack was
   just one idea, you could just as well allow only *one* error at a time
   thus have subsequent ones overwrite earlier ones, which is imho worse

the point that you don't seem to have gotten is: for an *exception-like*
scheme, you *must* deal with cases where multiple errors occour before
you can handle them.

but as said already, you probably didn't have an exception like thing
in mind, though on the other hand you added things like a module key to
your struct _GException (which isn't needed for *one-level* calls with
error handling), and were talking on "What information an exception
contains" with regards to "the Unix API".

now step back and rethink the issue, do you want to improve error reports
from immediate callees or do you want to alter normal flow-control of
a program (i.e. exception handling), which are two distinct and *very*
different things.
once you answer that question we can return to discuss an appropriate
design/implementation.

i'm not going to comment on the rest of your email where you mixed up
interpretation (probably due to me not outlining things crystal enough)
and analysis of my suggestion, since the whole discussion is moot untill
you decide what exactly you want.

> 
> Havoc
> 

---
ciaoTJ