Re: Exceptions and GObject-based libraries

[muppet <scott asofyet org>]

On Aug 27, 2004, at 8:10 AM, Andy Wingo wrote:

[snip explanation of why you can't longjmp() past g_signal_emit()]
> This is unfortunate, and really reduces the expressivity of using
> higher-level languages with gobject-based libraries. I seem to recall
> that python uses different return values to implement exceptions, but I
> know C++ has true non-local exits. I wanted to know how the rest of you
> deal with this situation.

perl uses C's setjmp() and longjmp() to implement eval() and die(), 
which are equivalent to catch() and throw() in other exception 
implementations, so we, too, ran across "interesting" problems with 
exceptions in signal handlers (usually resulting in segfaults and/or 
abort()s).

In a nutshell, we don't allow perl's exceptions to cross signal 
invocation boundaries.  This also means that we trap exceptions and 
don't let them cross mainloops, which has been a point of contention 
for some developers, but has precedent in other event systems.

Some initial discussion on the topic:
http://mail.gnome.org/archives/gtk-perl-list/2003-August/msg00294.html

The proposed resolution, which i believe is still in place.
http://mail.gnome.org/archives/gtk-perl-list/2003-August/msg00398.html



> Also, I wanted to know if there's interest in at least making GObject
> exception-safe.

i'm interested, of course, but i fear that this would have to be 
something that would go into a major version release, or at least 
something that breaks bincompat.  on the surface it seems that all 
you'd require would be changing the internals of signal emission to 
remove some assumptions, but i can't quite convince myself that this 
change in semantics would be completely compatible for old apps.  maybe 
it could.  timj is the real person to ask.


> Any thoughts? Am I crazy?

visionaries always seem crazy.  :-)


--
I don't have a drinking problem,
'cept when i can't get drink.
  -- Tom Waits