On Mon, Feb 8, 2016 at 6:21 PM, Michael Marcin
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 resultstd::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_ptrstd::string, and throw only in case of illegal entry. Cheers, Emil