Re: Proposal: make Glib::KeyFile easier to use

[Povilas Kanapickas <povilas radix lt>]

On 12/27/2013 12:08 AM, Aurimas Cernius wrote:
> Hi,
>
> > Okay. I think the following code that uses the current API 
> > illustrates my use case well:
>
> > if (f.has_key("a", "b") { // false is not unlikely bool parsed = 
> > false; int val; try { val = f.get_integer("a", "b"); parsed = 
> > true; } catch (...) { // unlikely } if (parsed) { fun(val); // 
> > fun() must called only if val is parsed // This is not
> > necessarily a function } } else { /* no code, not unlikely */ }
>
> > Two observations: * The keys are optional, thus exceptions can't
> > be used to handle the case when a key is not present * fun() must
> > not be called if the value has not been parsed correctly
>
> But... this works just as you want with exceptions, if you rewrite 
> code like this (I assume fun() to be a function here):

> try { fun(f.get_integer("a", "b")); } catch(Glib::KeyFileError &) {
> /* Not found or not parsed */ }

That's not an equivalent. I've written my code carefully to expose what
it takes to solve the issue properly. The rewritten code, while being
short, has the following two subtle issues:

 * Exceptions are used for the main control flow. That is, an exception
will be thrown whenever an optional key is not present. Since this is
not unexpected failure mode, it should not be handled via an exception.

 * I catch the exceptions that originate out of fun() too. While it is
unlikely that it may throw Glib::KeyFileError, this approach is
semantically wrong. Any bugs caused by this would be extremely hard to fix.

Regards,
Povilas