On exceptions, errors, and contract violations

[via Digitalmars-d]

On Sunday, 5 October 2014 at 21:16:17 UTC, Marco Leise wrote:
> I don't get this. When we say logic error we are talking bugs
> in the program.

By what definition?

And what if I decide that I want my programs to recover from bugs 
in insignificant code sections and keep going?

Is a type error in a validator a bug? It makes perfect sense to 
let the runtime throw implicitly on things you cannot be bothered 
to check explicitly because they should not happen for valid 
input. If that is a bug, then it is a good bug that makes it 
easier to write code that responds properly. The less verbose a 
validator is, the easier it is to ensure that it responds in a 
desirable fashion. Why force the programmer to replicate the work 
that the compiler/runtime already do anyway?

Is a out-of-range-error when processing a corrupt file a bug or 
it is a deliberate reliance on D's range check feature? Isn't the 
range check more useful if you don't have to do explicit checks 
for valid input? Useful as in: saves time and money with the same 
level of correctness as long as you know what you are doing?

Is deep recursion a bug? Not really.

Is running out of memory a bug? Not really.

Is division by a very small number that is coerced to zero a bug? 
Not really.

Is hitting the worst case running time which cause timeouts a 
bug? Not really, it is bad luck.

Can the compiler/library/runtime reliably determine what is a bug 
and what is not? Not in a consistent fashion.

> Why would anyone turn an outright bug into
> "cannot compute this". When a function cannot handle division
> by zero it should not be fed a zero in the first place. That's
> part of input validation before getting to that point.

I disagree. When you want to computations to be performant it 
makes a lot of sense to do speculative computation in a SIMD like 
manner using the less robust method, then recompute the 
computations that failed using a slower and more robust method.

Or simply ignore the results that were hard to compute: Think of 
a ray tracer that solves very complex equations using a numerical 
solver that will not always produce a meaningful result. You are 
then better off using the faster solver and simply ignore the 
rays that produce unreasonable results according to some 
heuristics. You can compensate by firing more rays per pixel with 
slightly different x/y coordinates. The alternative is to produce 
images with "pixel noise" or use a much slower solver.

> Or do you vote for removing these validations and wait for the
> divide by zero to happen inside the callee in order to catch
> it in the caller and say in hindsight: "It seems like in one
> way or another this input was not computable"?

There is a reason for why the FP handling in ALUs let this be 
configurable. It is up to the application to decide.