-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
On 12/27/2013 09:42 PM, Aurimas Cernius wrote:
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.
I can't agree with you on this point. Using exceptions for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
The current interface of Glib::KeyFile::get_* functions is quite
inconvenient as exceptions are the only reliable way to receive
error conditions. Consider the following example:
Glib::KeyFile f; ... int x = f.get_integer(a, b); // (1)
On 12/26/2013 09:05 PM, Aurimas Cernius wrote:
Hi,
The current interface of Glib::KeyFile::get_* functions is quite
inconvenient as exceptions are the only reliable way to receive
error conditions. Consider the following example:
Glib::KeyFile f; ... int x = f.get_integer(a, b); // (1)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
One external thing to consider here is who edits key files. I
don't expect non-pro guy doing anything there, so key files
probably are unlikely to be broken (low probability).
Yes, but I still don't want stack unwinding to occur. In my
On 12/26/2013 10:32 PM, Aurimas Cernius wrote:
...
I don't quite understand what you're trying to achieve. Your point
is to make Glib::KeyFile easier to use, but I don't really see,
how your proposal achieves that. Returning a wrapper object and
writing if to check it's value does not seem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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 (...) { //
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 (...) { //
Hi,
I think exceptions are the best to handle errors. They give more
information than an Option and are as fast in recent versions of GCC.
Moreover, semantically an Option is *not* an error.
Finally, when reading someone else's code, a try/catch means that code
can fail, whereas an Option
