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