3 ms·
Something that seems to get forgotten in these discussions is that there’s a big difference at runtime between exceptions and error flag return values. With er
by iainmerrick 8y ago
Something that seems to get forgotten in these discussions is that there’s a big difference at runtime between exceptions and error flag return values.
With error flags there’s a lot of code that runs all the time (although simple code with very predictable branches). A cycle or two in the common case, maybe tens of cycles for a branch mispredict in the error case.
Whereas exceptions (in the C++/Java style) are free when they don’t fire, but very expensive when they do -- hundreds or thousands of cycles to parse exception tables and unwind the stack.
Won’t anyone think of the runtime? :)
I tend to think exceptions are better language design since they give more freedom to use different implementation strategies. But of course that freedom isn’t really useful unless you know the programmer’s expectations about how often errors are likely to occur, and as others have noted that’s really the hard part of the problem.
- Rusky 8y ago> Whereas exceptions (in the C++/Java style) are free when they don’t fire, but very expensive when they do -- hundreds or thousands of cycles to parse exception tables and unwind the stack. This isn't the whole story. The unwind control flow edges inhibit optimizations and increase code size. This is part of why C++ added `noexcept`. On the implementation freedom side of things, I am inclined to agree. For example, C++ is considering reimplementing exceptions as return values under the hood: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070... (Though also note that an Either/Maybe/etc-style syntax could also be implemented as unwinding if you wanted to...)