3 ms·

Can you provide an example of that on godbolt or similar? In what scenarios do exceptions introduce the claimed cost? The only thing I could see is just the de

Can you provide an example of that on godbolt or similar? In what scenarios do exceptions introduce the claimed cost? The only thing I could see is just the density of code could mean more page spills and less efficient cache line usage for code. There's otherwise no actual cost to the assembly executed itself. And that's compared to no error handling at all, even. Compared to return values it's very clearly faster. But maybe there's some edge case you're aware of that does something different.

jandrewrogers 2y ago
Whether or not exception flow control has a cost, it forces you to add code elsewhere that does have a cost which only exists to make the program exception safe. Some objects cannot be safely destroyed at arbitrary points during program execution because it will corrupt memory, leak resources, etc. In a lot of systems-y code you can have things in-flight that the code can’t reliably stop or undo as an intrinsic property of the system. If errors occur, you have to partially defer the unwinding of state indefinitely (or block) until it is safe to do so. This is pretty idiomatic for things like high-performance I/O. Making this exception safe requires much more defensive programming. You need extra code on the happy path to collect context in case of an exception, extra code in the error path to interpret that context to figure out what is and is not safe to destroy at the point in execution where the exception occurred, and extra code in the handling path to execute the deferral logic based on an interpretation of the context. With return code style handling, this is usually implicit in the structure of the code. It is much nicer to do this at compile-time than run-time. If you only write high-level C++ then this might not apply but most C++ tends to be used for systems-y software these days. The widespread practice of disabling exceptions for C++ code bases at companies big and small didn’t happen for no reason.
- kllrnohj 2y ago
  > You need extra code on the happy path to collect context in case of an exception Again, provide an actual example please. C++ exception context handling is generated at compile time and is in a secondary, cold stack. It's unclear if you actually know of something specific or if you're just speculating on what you assume happens instead of what actually does

jandrewrogers 2y ago

Whether or not exception flow control has a cost, it forces you to add code elsewhere that does have a cost which only exists to make the program exception safe. Some objects cannot be safely destroyed at arbitrary points during program execution because it will corrupt memory, leak resources, etc. In a lot of systems-y code you can have things in-flight that the code can’t reliably stop or undo as an intrinsic property of the system. If errors occur, you have to partially defer the unwinding of state indefinitely (or block) until it is safe to do so. This is pretty idiomatic for things like high-performance I/O. Making this exception safe requires much more defensive programming. You need extra code on the happy path to collect context in case of an exception, extra code in the error path to interpret that context to figure out what is and is not safe to destroy at the point in execution where the exception occurred, and extra code in the handling path to execute the deferral logic based on an interpretation of the context. With return code style handling, this is usually implicit in the structure of the code. It is much nicer to do this at compile-time than run-time. If you only write high-level C++ then this might not apply but most C++ tends to be used for systems-y software these days. The widespread practice of disabling exceptions for C++ code bases at companies big and small didn’t happen for no reason.

kllrnohj 2y ago
> You need extra code on the happy path to collect context in case of an exception Again, provide an actual example please. C++ exception context handling is generated at compile time and is in a secondary, cold stack. It's unclear if you actually know of something specific or if you're just speculating on what you assume happens instead of what actually does