Comparing Exceptions and Errors

[Ola Fosheim Grøstad]

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.)

> It says that the programmer cannot attribute exactly where this 
> went wrong because otherwise, he would have accounted for it, 
> or thrown an Exception instead (or some other mitigation).

He can make a judgement. If this happened in a safe pure function 
then it would most likely be the result of what is what meant to 
do: check that the assumptions of the algorithm holds.


> Anything from memory corruption, to faulty hardware, to bugs in 
> the code, could be the cause.

That is not what asserts check! They will be removed if the 
static analyzer is powerful enough. All the information to remove 
the assert should be in the source code.

You are asserting that *given all the constraints of the type 
system* then the assert should hold.

Memory corruption could make an assert succeed when it should 
not, because then anything can happen! It cannot catch memory 
corruption reliably because it is not excluded from optimization. 
You need something else for that, something that turns off 
optimization for all asserts.


> Exactly. Use Exceptions if it's recoverable, Errors if it's not.

This is what is not true, asserts says only something about the 
algorithm it is embedded in, it says that the algorithm makes a 
wrong assumption, and that is all. It says nothing about the 
calling environment.


> A failed assert could be because of undefined behavior. It 
> doesn't *imply* it, but it cannot be ruled out.

And a successful assert could happen because of undefined 
behaviour or optimization! If you want these types of guards then 
you need to propose a type of asserts that would be excluded from 
optimization. (which might be a good idea!)

In the case of UB anything can happen. It is up to the programmer 
to make that judgment based on the use scenario. It is a matter 
of probabilisitic calculations in relation to the use scenario of 
the application.

As I pointed out elsewhere: «reliability» has to be defined in 
terms of the use scenario by a skilled human being, not in terms 
of some kind of abstract thinking about compiler design.