|
Boost : |
Subject: [boost] Fwd: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: degski (degski_at_[hidden])
Date: 2018-01-28 21:53:33
Accidentally sent privately, forwarded below:
---------- Forwarded message ----------
From: degski <degski_at_[hidden]>
Date: 28 January 2018 at 15:46
Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to
Sun-28-Jan, 2018)
To: VinÃcius dos Santos Oliveira <vini.ipsmaker_at_[hidden]>
On 28 January 2018 at 14:10, VinÃcius dos Santos Oliveira <
vini.ipsmaker_at_[hidden]> wrote:
> 2018-01-28 12:12 GMT-03:00 degski via Boost <boost_at_[hidden]>:
>
>> 1. Use of outcome is more manual and cumbersome, i.e. more error-prone.
>>
>
> What is complex about the following?
>
<snipped the code>
I'd just use boost::cnv::spirit and specify explicitly what happens when
conversion didn't work... much shorter, very well optimized (the best) when
it does work (the conversion)...
> Server side code...
>
There's more than servers in life. Handling f.e. O-O-M-situations is not
gonna help me on my lap-top... a re-think and re-write of my app is in this
case in order, though... or a trip to the shop and buy a bigger stick (both
the "slow path").
> If the error is exceptional or not, it depends on context, not on the
> algorithm (e.g. connection failure on game client code and game server code
> and both of them being backed up by the same functions). Boost.Outcome
> let's you do just that by converting an error into an exception.
>
Yeah, that's another discussion, isn't it? errors vs. exceptions. Should
exceptions be exceptional, or getting back to your conversion example,
should we use exceptions to indicate failure as this is the case in
Boost::Lexical_cast? I know the answer I like best, and moved on to
Boost.Spirit.
degski
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk