Re: Build problem Gtk2-1.037

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 ( 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.
        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

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