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

[Aurimas Cernius <aurisc4 gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

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

The only case it is not equivalent is if Glib::KeyFileError can be
thrown inside fun(), which would mean you're reading key file there too...


> 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 disagree. Expected failure is still a failure and can drop code
execution to error handling code. Reporting potentially non-fatal
error as exception is not ideal of course, but definitely possible.
If missing or non-parsable key falls back to the same code, it is
actually a good thing they both throw the same exception. The same
way, if non-parsable key throws exception, it's meaningful for
non-existing key to throw too (though I'd like more to pass default
value as additional argument).


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

As long as fun() does not throw Glib::KeyFileError, everything is fine
- - a written catch only handles this type of exception, all other types
are handled by enclosing try-catch. I don't see what is semantically
wrong and so error-prone with this.
Besides, reading about boost optional
http://www.boost.org/doc/libs/1_55_0/libs/optional/doc/html/index.html
I think KeyFile is somewhat in the middle between (A) and (C).
Throwing exception when key is unparsable is reasonable. When key is
missing, I'd expect most cases to be the same as with unparsable, the
remaining one can check for key existence. So really, I see no
advantage of optional idiom for key file.

- -- 
Aurimas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSvdgLAAoJECtTeRAzEaLP8RgIAJrUHDvdYeoVvdx1keoqaFew
2LnFQvMhtFvElZ/QwSpnwwZHP3vbjjpKc4DxQ7LtCU5P0CNw7dcYv2lvi4NQnnRN
5yprj5BxqpeZAnOUakfJo8DqNW9h6MAGnci3OVNUG/Ff7wzNQxBMWEccb7CxHn0H
X9gLepyR87emosXVaZa4t1RdIOrP6RlgxC+kTigzl4SRKa6uFr1q65V2TNK/IDX+
g5n8yBGLXxliJxu/qMQX9+WATqmm1SPTaUKLm7aSMGOZhdC9snug0p4Ok8owWirQ
vBiVD6HHRYIivYfFkAG6j9WPzbOTZSo4yIo6dmuiIqG9OgaLgSb9pl3WzTrSd08=
=ycD5
-----END PGP SIGNATURE-----