On Wed, May 24, 2017 at 12:16 PM, Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
On 24/05/2017 20:54, Emil Dotchevski via Boost wrote:
I don't dispute that exception handling has overhead and that you can construct a toy example that shows that. However, people who choose to avoid exceptions make a bigger claim, something along the lines of "in my domain we can't afford exception handling overhead". I have _never_ seen hard data to support this.
I have seen two use cases to avoid exceptions:
1) Any hard error won't be handled, because it's highly unlikely, and we don't want to use more space or CPU (depending on the implementation) in something that is very unlikely. For hard errors std::terminate or a log-and-die solution is a perfectly valid option for an application (e.g. when memory is exhausted or a logic error is detected). This could be the case for some games.
2) Hidden control paths are unacceptable. Typically safety or security critical systems where every single path or branch must be tested. Explicitly error handling shows every path and code review and coverage tools are very helpful. Writing exception safe code is error-prone, specially when operations that can throw can change implicitly when inner operations of a statement start throwing new classes. The exception type thrown by is not enforced by the compiler whereas the return type is fixed at compile time. Sometimes this makes error handling much easier.
Arguments similar to the ones you make in 2) can be made in support of exception handling as well. For example, returning error codes has many more points where bugs can occur, since failure-neutral contexts still must be concerned with failures. Under maintenance, unrelated seemingly innocent change in the control flow can easily introduce subtle bugs in the error-reporting branches. This problem is amplified by the fact that these branches are usually very difficult to test and analyze, therefore it is critical to adopt a programming style that avoids such bugs. I would conclude that writing exception-unsafe code is error-prone, both during the initial development and under maintenance. I would typically recommend writing exception-safe code even if you don't use exceptions. That said, you're making good points, both are arguments about the semantics of exception handling rather than the overhead of it. My initial objection if you want to call it that is that the general attitude of Outcome seems to be "exceptions are slow and so C++98, what are you, a neanderthal?" :) whereas I see Outcome as lowering the level of abstraction to where it is in other languages which force programmers to laboriously deal with failures explicitly (which is prone to errors) -- for no good reason at all.