2017-01-17 13:27 GMT+01:00 Niall Douglas
It's no problem. Most on the committee think exceptions are the correct way of reporting errors because they clutter up code the least. I think that's right for a range of code bases. I also think that's wrong for a range of code bases. Depends on the code base. In particular, for some code bases you really must *require* the programmer to explicitly code what happens when an error occurs. What you see before you is always taken more seriously by other programmers than automatic execution paths chosen silently for you by the compiler.
Thanks for a detailed reply. This is what I understood so far. One of the main goals of Boost.Outcome (apparently not the only one) is to make it easy for you to go from an island of exceptions into the sea of noexcept (and probably the other way around also). The reason you would encourage the explicit control path over the implicit one (where exceptions are thrown around) is for the correctness of the program -- not necessarily performance. Did I summarize it correctly? If yes, there comes another question. One of the main reasons exceptions were introduced in the first place was to be able to report failures from functions that cannot use the return value for this purpose: constructors, conversion operators, and other operators. How do you deal with these functions in the sea of noexcept? Regards, &rzej;