Convert library to use Boost.Optional?
Hi Vladimir, I have just made one observation regarding the return type. Now, that you are using your custom boost::convert<TypeOut>::result, you can choose what exception type you want to throw from function value(). Your current choice is probably not the best one because you cannot distinguish with a type alone between the failure to convert form string to T from any other std:: invalid_argument thrown in a big program. I recommend that you invent your own type that can derive from std::invalid_argument. This will work fine, but the problem will reappear when you switch to boost::optional, because the latter is a general purpose library and it does not know the history behind the failure. It will throw a generic "empty optional" error rather than something speciffic to conversions. So, there is one disadvantage of using boost::optional. I do not know how important you consider it to be. If it is a deal, and you do not want to invent your own return type. Perhas you could use 'Expected': http://www.hyc.io/boost/expected-proposal.pdf. It is proposed for Standard C++, And I think some work is being done to include it into Boost too. It is similar to Boost.Optional, but conveys more information about the reason of failure. Might be worth considering. Regards, &rzej
On 05/21/2014 07:45 PM, Andrzej Krzemienski wrote:
Hi Vladimir, I have just made one observation regarding the return type. Now, that you are using your custom boost::convert<TypeOut>::result, you can choose what exception type you want to throw from function value(). Your current choice is probably not the best one because you cannot distinguish with a type alone between the failure to convert form string to T from any other std:: invalid_argument thrown in a big program. I recommend that you invent your own type that can derive from std::invalid_argument. This will work fine, but the problem will reappear when you switch to boost::optional, because the latter is a general purpose library and it does not know the history behind the failure. It will throw a generic "empty optional" error rather than something speciffic to conversions. So, there is one disadvantage of using boost::optional. I do not know how important you consider it to be. If it is a deal, and you do not want to invent your own return type. Perhas you could use 'Expected': http://www.hyc.io/boost/expected-proposal.pdf. It is proposed for Standard C++, And I think some work is being done to include it into Boost too. It is similar to Boost.Optional, but conveys more information about the reason of failure. Might be worth considering.
Andrzej, thank you for your input and suggestions. I glanced over (it was already quite late) the expected-proposal.pdf (can't say I understood everything) and I read/watched about Alexandrescu's Expected before. Initially deploying it seemed kinda tempting/interesting as indeed it's capable of conveying more information about failure reasons. Then I tried to see if I personally need/care for that additional information... so far it turns out I don't. I just do not have one single piece of code which would try to analyze the failure, correct something and then re-try conversion after it fails the first time around. More so, more elaborate reporting about conversion failure might be outright not possible. Say, I apply several formatting options to std::stringstream and conversion fails. std::stringstream does not tell me what exactly caused the failure, does it? More so, lexical_cast simply reports "conversion failed" and I do not remember ever reading any requests to extend that frugal reporting. So, there seems no need/appetite for such failure reporting. With that conclusion I feel sticking to/with std::tr2::optional or updated coming boost::optional. What do you think? Does it make sense?
2014-05-22 0:18 GMT+02:00 Vladimir Batov
On 05/21/2014 07:45 PM, Andrzej Krzemienski wrote:
Hi Vladimir, I have just made one observation regarding the return type. Now, that you are using your custom boost::convert<TypeOut>::result, you can choose what exception type you want to throw from function value(). Your current choice is probably not the best one because you cannot distinguish with a type alone between the failure to convert form string to T from any other std:: invalid_argument thrown in a big program. I recommend that you invent your own type that can derive from std::invalid_argument. This will work fine, but the problem will reappear when you switch to boost::optional, because the latter is a general purpose library and it does not know the history behind the failure. It will throw a generic "empty optional" error rather than something speciffic to conversions. So, there is one disadvantage of using boost::optional. I do not know how important you consider it to be. If it is a deal, and you do not want to invent your own return type. Perhas you could use 'Expected': http://www.hyc.io/boost/expected-proposal.pdf. It is proposed for Standard C++, And I think some work is being done to include it into Boost too. It is similar to Boost.Optional, but conveys more information about the reason of failure. Might be worth considering.
Andrzej,
thank you for your input and suggestions. I glanced over (it was already quite late) the expected-proposal.pdf (can't say I understood everything) and I read/watched about Alexandrescu's Expected before. Initially deploying it seemed kinda tempting/interesting as indeed it's capable of conveying more information about failure reasons. Then I tried to see if I personally need/care for that additional information... so far it turns out I don't. I just do not have one single piece of code which would try to analyze the failure, correct something and then re-try conversion after it fails the first time around. More so, more elaborate reporting about conversion failure might be outright not possible. Say, I apply several formatting options to std::stringstream and conversion fails. std::stringstream does not tell me what exactly caused the failure, does it? More so, lexical_cast simply reports "conversion failed" and I do not remember ever reading any requests to extend that frugal reporting. So, there seems no need/appetite for such failure reporting. With that conclusion I feel sticking to/with std::tr2::optional or updated coming boost::optional. What do you think? Does it make sense?
Sure it does. I just realized that there is this trade-off to be made that I was not aware earlier. It looks like you are already aware of it and have made your call. That's fine. Regards, &rzej
participants (2)
-
Andrzej Krzemienski -
Vladimir Batov