Re: Return values from gtk2 widget (void) methods

[muppet <scott asofyet org>]

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


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