Making Errors errors

[sighoya]

On Thursday, 28 January 2021 at 19:42:54 UTC, Paul Backus wrote:
> From now on, whenever this topic comes up, I'm just going to 
> post this link:
>
> http://joeduffyblog.com/2016/02/07/the-error-model/#bugs-arent-recoverable-errors

I haven't consumed the whole page, but the examples of both 
sections (bugs vs recoverable errors) seems to overlap to some 
extent which justifies the statements I made.

It is sometimes very hard to distinguish between bugs and 
recoverable errors (which mostly aren't recoverable anyway, i.e. 
the term is confusing).

A bug is even misleading here because it doesn't relate to error 
handling only, the majority of bugs doesn't cause errors just 
silently change the expected result.

A bug is just the mismatch of specification and implementation. 
It makes sense to model them in language with formal verification 
requiring the compiler to reject your program if the 
specification doesn't match the implementation.

Given range indexing as an example, we would certainly think of 
index violations as bugs. That may be true. However, the code 
following after the random access wouldn't be executed anyway and 
the caller may or may not depend hard on the result of the code 
fragment.

A better take to go would definitely exclude pessimistically 
out-of-range-errors and bubble up possible errors on a higher 
level of understanding but that's even hard to do with (path) 
dependent typing.

The cost is simply too high to support and more overly to adapt 
such fine-grained modeling.

And introducing errors/bugs in addition to exceptions bifurcates 
your world again in two parts. I know that errors exist in Java 
and probably in C# too, but they never really surfaced in 
productive development or just no one cares about them as their 
classification as errors is generally debatable.