[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [RFC] Gnome2::GConf error handling
- From: Emmanuele Bassi <bassi-e libero it>
- To: gtk-perl-list gnome org
- Subject: Re: [RFC] Gnome2::GConf error handling
- Date: Wed, 24 Sep 2003 21:56:00 +0200
* muppet <scott asofyet org>:
> > * 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",
Exactely. Although I really don't know much about failures, since I've
never had one (lucky guy ;-)), and I've never spent much time inside
GConf sources.
> and you might want to fail over to a different backend?
Backends aren't changeble by the user (that is, the GConfClient object),
but by the engine. But, since GConf is a general purpose library, I
think that could be possible.
> > 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.
My proposal had the prerequisite of not breaking any of the existing
code (even though it's a *very* small codebase, I think). The optional
"err_sub" parameter would be completely optional, and the default
behaviour should be the "usual" one (no programmer-defined error
handling).
> i don't think it should preclude the caller connecting his own
> signal handlers explicitly.
I don't too.
Regards,
Emmanuele.
--
Emmanuele Bassi (Zefram) [ http://digilander.libero.it/ebassi/blog ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738 08BD 8ECC DB8F A432 0FF4
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]