Re: Exceptions and GObject-based libraries

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:

The proposed resolution, which i believe is still in place.

Also, I wanted to know if there's interest in at least making GObject

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]