Re: Return values from gtk2 widget (void) methods

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

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

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

Daniel Lacroix

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