Re: [boost] Convert library to use Boost.Optional?

Subject: Re: [boost] Convert library to use Boost.Optional?
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-05-21 18:18:55

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?