Re: Return values from gtk2 widget (void) methods

[Daniel Lacroix <dlacroix erasme org>]

Le mer 23/10/2002 à 07:08, muppet a écrit :
> [argh... just realized that mozilla has been replying to sender only 
> instead of the list when i hit "reply"...  sorry.]
>
> Dermot Musgrove wrote:
>
>  >Guillaume Cottenceau wrote:
>  >
>  >
>  >[...]
>  >
>  >
>  >>>Perl's eval() seems able to get and return errors (in $@) so I assumed
>  >>>that it would be possible in Gtk2-Perl too but if this is not the
>  >>>case then I suppose that we'll have to go with returning whatever
>  >>>the gtk2 function returns.
>  >>>
>  >>>
>  >>I don't see what's your idea with eval.
>  >>
>  >>
>  >I was just wondering if Perl can do it (trap errors in $@) why can't
>  >Gtk2-Perl? Is $@ loaded from STDERR or is there some nice generic way
>  >to trap gtk2 error messages so that a central error handler could
>  >determine success or failure.
>  >
>  >
>
> [this is all based on my working understanding from lots of perl use and
> recall from the man pages.  i could be quite wrong, please correct me if
> so.]
>
>
> die and croak kill the current interpreter; eval launches a new
> interpreter[1] on the eval'd code, so a die or croak returns control
> immediately to the calling interpreter, with the error string.
>
> this has the same effect as longjmp in C and throw in C++ --- you jump
> way back up the stack to some predefined point.  the reason for
> try/throw/catch is to allow destructors to be called cleanly as the
> stack unrolls; eval gets that when the new interpreter[1] cleans up.
>
> GLib2 has an exception mechanism, which GLib2 and Gtk2 themselves don't
> use because they are intended for lib clients' use.
>
>
> but having said all that, i don't think that Gtk functions fail in a way
> that would be meaningful to catch here.  casting and null-pointer errors
> spit something to the current log handler;  possibly GtkPerl could
> redirect that log handler and monitor it for things to flag, but that
> would be a performance hit for questionable gain.  in my experience,
> when Gtk runs into big errors, it usually just deadlocks because it
> can't communicate with the X Server, which is a hard situation to weasel
> out of.
>
>
> i actually would be quite happy if the perl versions of the Gtk
> functions followed as closely as possible the (important) semantics of
> the C version --- that way, the more detailed documentation for the C
> libraries is also useful for the perl bindings.  there are only a few
> functions with return values important for error-handling, anyway.

I do share this point of view. I prefer a Gtk2-Perl implementation which
stick to the C libraries. That way I can use the C doc to write my Perl
program. Else, a Gtk2-Perl documentation will be a necessity. I know
that the Gtk-Perl version was not always doing that but I thing it was a
mistake (because no doc was given). The only exception is multiple
returned values. When pointer on data are given in C, we should
translate that in multiple returned values and no pointer on data.

For error handling in Gtk2, there is no need to check all returned
values because Gtk2 will simply fails (program stop) if a major error is
reported (like not enough memory to work). All the rest is just
fonctionnalities. 

> [1] doubtless it's more complicated than that in the implementation, but
> i'll use this simplification for brevity's sake.
Daniel Lacroix