Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-02-10 16:30:53

On 11/02/2016 08:40, Emil Dotchevski wrote:
> It doesn't matter what your use case is: while the success/failure
> vocabulary isn't incorrect, it is more precise to think in terms of
> postconditions. You call a function, it will either satisfy its
> postconditions or it won't return. Sure, you can and should return all
> information that the caller needs in order to proceed with whatever
> operation is being attempted, but there is no need to return anything if
> the operation can't proceed.
>
> So all you need to do is correctly identify the conditions that indicate
> that the operation can't proceed, and throw an exception.

That's still a fuzzy line though.  In the delete file case, the 
operation of deleting the file cannot proceed because the file is 
already absent.  However the post-condition of "the file no longer 
exists" is still met.  Is that success or failure?

There are other cases where an operation might fail, or (if you prefer 
that term) be unable to proceed (eg. "queue is full, cannot push new 
item"), but throwing an exception in this case is not a good design 
choice unless you *know* that the queue is never supposed to be full -- 
which is not something that the queue itself can know unless it's a 
supposedly unbounded queue and so the only way it can be full is if it 
cannot allocate more memory.

But for bounded queues, the library generally has to assume that it 
could reach the bound at some point and have to refuse to add new items, 
so that should be a status return rather than an exception.  And yet the 
application could choose to use such a queue with a really large bound 
or with a producer that's massively slower than the consumer, and so the 
assumptions the library made about the balance of success vs. failure 
weren't correct.