Re: Build problem Gtk2-1.037

[muppet <scott asofyet org>]

BIG NOTE: we are freezing API presently.  If you want to propose any 
changes to the gtk2-perl API or to the way gtk2-perl behaves, we must 
talk about them NOW.


On Monday, March 1, 2004, at 10:49 AM, Thierry Vignaud wrote:

> Ross McFarland <rwmcfa1 neces com> writes:
>
> > to get it to work with some of their tools.
>
> one shot exception handlers are just insane in big apps.
> do you expect us to set us an handler that manage all kind of
> exceptions on every callbacks?
> this is a totally insane policy.
> you want exception throwed from callbacks to go up until sg care about 
> them.
> you do not want every piece of code to deal with thousands of possible 
> problems totally unrelated to what they do and which they do not know 
> what do to do about.

a few technical points:

- Glib's GClosure exception handlers are not one-shots --- you can have 
them act like one-shots if you return FALSE.  If you return TRUE, the 
handler stays installed.  The fact that they are global and all of them 
run allows you to implement fine-grained handling.

- The idea of trapping exceptions during main loops has precedent 
(Event.pm).  There are also technical reasons (if you jump past a 
gtk_main() stack frame you can't get out of it).

- Given the above, you can very easily install an exception handler 
that kills the main loop and cleans up properly.  It's difficult to the 
point of senselessness to get the semantics of this right in a library, 
because it's truly the app's responsibility.

For the case of a click on a cancel button in a wizard as something to 
jump you back to the calling context (if i'm recalling that thread 
correctly), you could do this:

  # in library code that launches the wizard
  Glib->install_exception_handler (sub {
        if ($_[0] =~ /wizcancel/) {
                Gtk2->main_quit;  # stop the enclosing main loop
                ${$_[1]} = $_[0];  # let the owner know
                # uninstall yourself; we'll reinstall before the next wizard launch.
                FALSE;
        }
        return TRUE;  # try again
  }, \$wizard_canceled);

Checking $wizard_canceled is no different from checking $@, after all.

Of course, how you implement that depends completely on how your app is 
defined and how you do things.


> our solution did fix quite some issues like gratuitous ERRSV clobberin
> and the like that i'd to send fixes again.

i applied your patch that avoids clobbering $@, and the most recent 
change was to avoid clobbering $_.  if there are others, please send 
them.


> you choose to ignore all errors by default which is an insane policy
> as far as i'm concerned.

Technically, we don't ignore all errors by default.  We *trap* 
exceptions that go uncaught and would otherwise cause extreme breakage; 
by precedent for event-based system we do not kill the event loop, but 
we do also give you a hook to handle those exceptions, so they are far 
from ignored.


The one failing i see is that if you have any exception handlers 
installed, you won't get warnings, regardless of whether the exception 
is "handled".  I'm open to proposals for fixing that, but be quick, as 
our freeze date is *today*.


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