Comparing Exceptions and Errors
Steven Schveighoffer
schveiguy at gmail.com
Mon Jun 6 17:52:12 UTC 2022
On 6/6/22 12:15 PM, Ola Fosheim Grøstad wrote:
> On Monday, 6 June 2022 at 15:54:16 UTC, Steven Schveighoffer wrote:
>> If it's an expected part of the sorting algorithm that it *may fail to
>> sort*, then that's not an Error, that's an Exception.
>
> No, it is not expected. Let me rewrite my answer to Sebastiaan to fit
> with the sort scenario:
>
> For instance, you may have a formally verified sort function, but it is
> too slow. So you optimize one selected bottle neck, but that cannot be
> verified, because verification is hard. That specific unverified
> softspot is guarded by an assert. The compiler may remove it or not.
>
> Your shipped product fails, because the hard to read optimization wasn't
> perfect. So you trap the thrown assert and call the reference
> implementation instead.
>
> The cool thing with actors/tasks is that you can make them as small and
> targeted and revert to fallbacks if they fail.
>
> (Assuming 100% @safe code.)
Then that's part of the algorithm. You can use an Exception, and then
handle the exception by calling the real sort. If in the future, you
decide that it can properly sort with that improvement, you remove the
Exception.
That is different from e.g. using a proven algorithm, like quicksort,
but failing to implement it properly.
-Steve
More information about the Digitalmars-d-learn
mailing list