Re: [boost] expected/result/etc

Subject: Re: [boost] expected/result/etc
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2016-02-09 02:27:09

On Mon, Feb 8, 2016 at 6:21 PM, Michael Marcin <mike.marcin_at_[hidden]>
wrote:

> Using result<T> doesn't preclude exception handling. I think they work
> very well together.
>

If you mean that they can work together within the same program, that's
obviously true. At some level it's all C and it's all error codes, so
arguably you can't escape them.

But of course the two approaches use completely different strategies. In
one case the programmer has to write if( error ) return error, like a
neanderthal. In the other, he has to write exception-safe code but the
upside is less error handling bugs, which is important as error handling
code is notoriously difficult to test.

Yes, with exceptions you do get different performance between the error-no
error paths, and that is critical in some applications, but these are
extremely specialized. In these cases one can't use dynamic memory
allocations either, which renders a lot of standard C and C++ functions off
limits, not only exception handling.

> i.e. in the case of text entry you might return a result<std::string>
> valid text would return directly
> invalid text would return an error code
> failure to allocate memory for the std::string would throw an exception

In the wild I've never seen a bad_alloc from std::string, except when it
was caused by a logic error in my program. If exceptions are used just so
that std::string can throw bad_alloc, that's 1) not worth the overhead of
exception handling and 2) extremely difficult to test..

Besides, in the case of text entry I doubt very much that the difference in
performance between the error-no error paths would matter in practice.

Of course sometimes you may need to distinguish between "nothing entered"
and "empty string entered" without signalling an illegal entry. In this
case you can simply return shared_ptr<std::string>, and throw only in case
of illegal entry.

Cheers,
Emil