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.
