I like how Zig implements exceptions. It is similar to the restricted exception value type proposal for C++, but it also has a nice bonus of recording some stack trace on the unwind path. Plus in Zig any call to a function has to either catch the exception or annotate the call somewhat similar to ? in Rust.

I'm not convinced a recursive implementation of `fib` is a reasonable example to draw such a conclusion.

It really isn't.

People need to stop making trivial benchmarks and draw ... silly ... conclusions.

http://www.eecs.northwestern.edu/~robby/courses/322-2013-spr...

It is a fact that C++ exceptions are largely low overhead, and that you also don't have to use them. In fact, C++ can make everyone happy, because you can choose which parts you like.

Personally, knowing how exceptions are implemented and having implemented small parts of the ABI, I can safely say that I will be using exceptions where appropriate in all my C++ projects. Parts where real-time behavior is needed we can use custom containers that don't randomly exit on failure. On low-memory hardware it is beneficial to have either tiny exception footprint or no exceptions at all.

It is true that C++ exceptions as they are implemented can be improved upon, breaking ABI. There are also other contenders (Herbceptions) that show great promise, bringing another way of handling exceptions that is not source compatible. Either way, many who work with custom C++ code do not care much about ABI, as everything is source compiled, and such would benefit from a new ABI generation.

Zero-overhead exceptions by Herb Sutter: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...

Of course the fib example is extreme. But some code bases do a lot of calls, and people care about calling overhead. I think a moderate calling overhead like, e.g., with Herbecptions is acceptable, because usually people doing something useful in a function that will mask the calling overhead. But other approaches are really to expensive to justify, they violate the zero-overhead promise of C++.

It is not trivial in practice to make code safe in presence of exceptions even if one follows the best C++ practices. The errors can be very subtle and hard to identify. It is another reason besides the performance and code bloat why Chromium disables them.

The article explains that they close that as a simple example of a workflow that is heavy on function calls.

> Very interesting that exceptions have much less overhead on the happy path than Rust/Haskell style Either types

C++ genuinely traded “error” cases (made them even costlier) so that the happy path of exceptions would be cheaper. I don’t remember whether that’s the case in C++, but in some language/implementations (used to be a big issue in V8) just having a try/except would drastically deoptimise a function, even if the exception never happened.

I'm curious whether Rust's Result gets special optimization treatment from the compiler that std::expected doesn't