Raymond Chen's take on so-called zero cost exceptions

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Tue Mar 1 10:30:42 UTC 2022


On Monday, 28 February 2022 at 23:01:46 UTC, Guillaume Piolat 
wrote:
> Performance is imo a false concern here since 1. either code 
> that should be fast is devoid of eror handling in the first 
> place 2. correctness of whole codebases is at stake 3. you can 
> always make a correct program faster, but there will be noone 
> to realize the incorrect program is incorrect.

Yes, that is my experience as well. You try to avoid the need for 
error-handling and if errors can arise you delay the handling of 
it.

Examples:
- In a parser you can build a log, then check the log after 
parsing.
- In a raytracer you can tag a pixel as failed and check it at 
the bottom level and retry with better solvers (or a slightly 
different angle or whatever).

Complex error situations usually are most relevant in I/O, but in 
order to get the highest performance I/O you have to special case 
all the I/O code to the platform and use whatever response 
mechanism the platform provides. If you are creating a library 
abstraction you won't get optimal performance anyway and 
exceptions tend to have smaller impact than other sources for 
latency.

I probably would not want to use unchecked exceptions for 
embedded, but that is a different discussion.



More information about the Digitalmars-d mailing list