Le 23/05/2017 à 18:52, Emil Dotchevski via Boost a écrit :
On Tue, May 23, 2017 at 7:37 AM, Niall Douglas via Boost < boost@lists.boost.org> wrote:
You could wholly replace all usage of C++ exceptions with Outcome without losing fidelity of error information.
(I wouldn't advise that you should, but you can)
You would thus exchange (slightly) worse performance of successful code in exchange for vastly better and predictable performance of unsuccessful code.
I keep seeing the assertion that C++ exceptions create performance problems but I am yet to see actual data to support it. Not a simple toy case but an actual program that was shown to be slow when using exceptions, that issue couldn't be fixed otherwise and the solution was to not use exceptions.
Practically speaking exception handling overhead occurs only at function entry and exit. It disappears in thin air (all of it) by simply inlining the function, which would be done in performance-critical parts of the code anyway (and MSVC, whose exception handling overhead is probably the worst, can inline functions even at link time.)
So I must ask: what is the practical problem solved by not using exceptions in general and Outcome in particular? It seems to me this is driven by a design preference for one coding style over another, which is fine, but nobody seems to be having that discussion. The cost of not using exceptions is that we're throwing away the ability to enforce postconditions. What's the upside?
Emil, I see expected as an alternative to output return codes, not to exceptions. We have output return codes in Filesystem. I adopted them in Boost.Chrono and Boost.Thread. I regret it. If I have had expected at the time, I would had used expected. We can restrict the expected interface to avoid exception in some cases. This introduce other issues, as constructors can not return anything they must be replaced by factories that return expected. This impose a big change on the way we program in C++, but people that don't use exception have already to do something like that. expected makes all this error handling more uniform. Again, expected in not incompatible with exceptions. Vicente