Re: [RFC] Gnome2::GConf error handling

["muppet" <scott asofyet org>]

Emmanuele Bassi said:
> * Summary & Considerations

wow, that's awfully complicated for something that, at face value, should
either have a key or not.  i guess the other situations are "permission
denied" or "couldn't connect to database server" or "prefs file doesn't
exist", and you might want to fail over to a different backend?


> * Situation in the Perl binding
>
> Actually, every fallible function that has the GError parameter in its
> signature, has a GError silently passed to it, and aborts on failure
> using croak(); it is completely transparent from the Perl programmer's
> point of view, and it's good for debugging.  This is, as a matter of
> fact, an acceptable compromise since the programmer may listen to the
> "error" callback (as soon as I modify it to pass the Perl equivalent of
> the GError structure[1]) or change the default error handler (this is
> yet to be implemented).

i think this works well, because you get two ways in which can set up traps
for errors that you want to catch.

   eval {
       a bunch of stuff that can croak
   } or {
       handle the failure or die if you can't
   }

or

   set up some traps
   eval {
       do a bunch of stuff that can croak.
   } or {
       alert user about unhandled errors and die
   }

the first style has the advantage that the block will be aborted on the first
croak.  the second style has the advantage that we'll only abort the croakable
block when it's something we can't handle with the traps.


> here's my RFC: every
> fallible method of Gnome2::GConf::Client will have an optional argument,
> which will be used to pass an error handler sub; internally, the binding
> will provide to connect that sub to the "unhandled_error" signal, thus
> removing the need for the programmer to connect a that sub to the
> "unhandled_error" signal; e.g.:
>
>   my $client = Gnome2::GConf::Client->get_default;
>   my $str = $client->get_string("/test/app/key", sub {
>         print STDERR "Error while retrieving data from /test/app/key\n";
>       });

so long as $client->get_string ($key) and the simple forms outlined above are
still available, this could be handy for workarounds and other sticky
situations.  i don't think it should preclude the caller connecting his own
signal handlers explicitly.


> Another way of handling that would be passing a boolean parameter, which
> would be internally checked for wheter passing or not a GError to the
> bound function, and letting the programmer explicitly connect a callback
> to the "unhandled_error" signal, e.g.:
>
>   $client->signal_connect(unhandled_error => sub {
>         my $err = shift;
>         print STDERR "Error: %s\n";
>       });
>   my $str = $client->get_string("/test/app/key", TRUE);

not so keen on this as a replacement for the above.  requires the perl
programmer to know a little too much about what's going on under the hood.

you could get this behavior as a side effect of the more powerful
optionally-supplied-sub implementation.


-- 
muppet <scott at asofyet dot org>