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



-----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 use
case the rest of the key file must still be read successfully. If
it was possible to give up on errors I would move error handling
somewhere higher up in the call stack and use exceptions.

You can wrap every individual call to get_* with try-catch (write your
own helper function for this). Should such convenience method be part
of Glibmm itself is a debate, of course.


Do think that "if" is more convenient that "try-catch"? I'm not
sure about that. If you think of more convenient getter for key,
I'd think of passing default value as last argument, that would
be returned in case key is missing or not valid. I think that
would cover most of the cases, the remaining few could deal with
exceptions.


Yes, I think that a simple conditional is a better approach in
this specific use-case: * Using exceptions to rewind the stack by
one level is fundamentally wrong. One can do that, but that's not
idiomatic C++.

No, that's what exceptions were designed for. What is wrong is
wrapping every statement in try-catch.


* Using a default value is not workable when the range of input
data must not be reduced (which is one of my requirements).

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 to be "easier" than wrapping a call
in try-catch:

int val;
try {
  val = key_file.get_integer("a", "b");
}
catch(Glib::KeyFileError &) {
  val = 0;  // let this be default value
}


int val;
auto opt = f.get_integer_opt("a", "b");
if(opt) {
  val = *opt;
}
else {
  val = 0;  // let this be default value
}


As you can see, your proposal in my case result in more code.
Can you present a use-case, where it makes things easier?

- -- 
Aurimas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSvJJjAAoJECtTeRAzEaLPFiwH/j4XGOvlJNfhU+u4Vng2FDI1
rRlHd2oQQLxbYNGPPvMdWxfThxKWQHLnhsbuvswO4APOXXO3xu92YlmapUNUdrkM
IVsOjq8soWluUH9ZYOAOq6JCDqorN+yd481ZiMgyOIw1GRcABQUsIEqVjkYC6euD
RHgVnHWIoE1+OsAY6hWuN/uv8aJ/SqQ4WnsrNIlH5gALRAuEfGs2kPBH0o6emIia
rOXjwPCYfkb4hYGhoS3wdq52y7Xjn+siN8VhvL7JNxFr/49xZZuXd5f6mXhjSXar
+MEc4QLUuHu1r7zjx/cP/s2cwjWHhS2Mc52zLxBOfW+d5rVp8HMqXO63xObSmkA=
=Mqfq
-----END PGP SIGNATURE-----


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]