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