Program logic bugs vs input/environmental errors

[via Digitalmars-d]

On Monday, 29 September 2014 at 04:57:45 UTC, Walter Bright wrote:
> Lots of bad practices are commonplace.

This is not an argument, it is a postulate.

>> You are arguing as if it is impossible to know whether the 
>> logic error is local
>> to the handler, or not, with a reasonable probability.
>
> You're claiming to know that a program in an unknown and 
> unanticipated state is really in a known state. It isn't.

It does not have to be known, it is sufficient that it is 
isolated or that it is improbable to be global or that it is of 
low impact to long term integrity.

> Are you really suggesting that asserts should be replaced by 
> thrown exceptions? I suspect we have little common ground here.

No, regular asserts should not be caught except for mailing the 
error log to the developer. They are for testing only.

Pre/postconditions between subsystems are on a different level 
though. They should not be conflated with regular asserts.

> A vast assumption here that you know in advance what bugs 
> you're going to have and what causes them.

I know in advance that a "divison-by-zero" error is of limited 
scope with high probability or that an error in a strictly pure 
validator is of low impact with high probability. I also know 
that any sign of a flaw in a transaction engine is a critical 
error that warrants a shutdown.

We know in advance that all programs above low complexity will 
contain bugs, most of them innocent and they are not a good 
excuse of shutting down the entire service for many services.

If you have memory safety, reasonable isolation and well tested 
global data-structures it is most desirable to keep the system 
running if it is incapable of corrupting a critical database.

> You're using exceptions as a program bug reporting mechanism.

Uncaught exceptions are bugs and should be logged as such. If a 
form validator throws an unexpected exception then it is a bug. 
It makes the validation questionable, but does not affect the 
rest of the system. It is a non-critical bug that needs attention.

> Whoa camel, indeed!

By your line of reasoning no software should ever be shipped, 
without a formal proof, because they most certainly will be buggy 
and contain unspecified undetected state.

Keep in mind that a working program, in the real world, is a 
program that provides reasonable output for reasonable input. 
Total correctness is a pipe dream, it is not within reach for 
most real programs. Not even with formal proofs.