2 ms·
Exceptions have hidden costs that are hard to spot. For example, generated assembly for C++ code with or without noexcept can be quite different. Part of the re
by gmueckl 6y ago
Exceptions have hidden costs that are hard to spot. For example, generated assembly for C++ code with or without noexcept can be quite different. Part of the reason is that DFA based optimizations get overwhelmed by the number of implied execution paths when exceptions may be thrown. So the optimizer essentially is forced give up more often, resulting in slower code for the normal case. This is orthogonal to any binary size issues from linking the runtime support for exceptions.
- kllrnohj 6y agoOf course, but that's comparing error handling code with non-error handling code. The comparison you need to make is instead exceptions vs. return values. Unless you're going to argue all errors should abort by default or similar. I do wish noexcept had better support, or was even the default (C++ and wrong defaults, a tale as old as time). But it's disingenuous to compare exceptions against nothingness.
- gmueckl 6y agoNo, this holds in a fair comparison with manual error checking. In the presence of possible exceptions, the compiler has to make the assumption that any nontrivial expression can throw, especially if its implementation is opaque at the callsite. With explicit error handling, this is reduced to those checkpoints that are inserted manually, which are generally fewer. If you call a function within the condition of an if statement, the compiler needs to conservatively assume that the execution flow from there is either to the rest of the conditionsl or to either one of the catch blocks or the functions' stack unwinding. If there cannot be an exception, the execution flow has none of these additional branches that bog down the DFA.