Program logic bugs vs input/environmental errors

Nick Sabalausky via Digitalmars-d digitalmars-d at puremagic.com
Sat Oct 4 13:58:07 PDT 2014


On 09/28/2014 04:13 PM, Walter Bright wrote:
>
> A program bug is, by definition, unknown and unanticipated. The idea
> that one can "recover" from it is fundamentally wrong.

In many cases you can. Don't forget, enterprise code aside, we're not in 
the days of spaghetti code where everything's directly intermingled: 
Things are encapsulated. If I call on a component, and that component 
fails, chances are the problems exist purely within that component. So 
yes, recovery is most definitely possible. Not *always*, but often.

I imagine you're about to jump on that "chances are" and "not always" 
part...and you're right: For safety-critical software, relying on that 
"*chances are*" the bug exists purely within that component is, of 
course, completely inappropriate. I won't dispute that.

But a LOT of software is *NOT* safety-critical. In those cases, going 
through the trouble of process-separated components or complete 
shutdowns on every minor compartmentalized hiccup, just on the 
off-chance that it might be symptomatic of something bigger (it usually 
isn't) usually amounts to swatting a fly with a bazooka.

If tetris, or "semi-interactive movie of the year", or a music library 
manager, or an online poll, or youtube comments suddenly goes haywire, 
it's really not a big deal. And process separation and permissions still 
limit the collateral damage anyway. It's unprofessional, sure, all bugs 
and crashes are, but it's certainly no less professional than a program 
that shuts down whenever the digital wind shifts.

Also, on a somewhat separate note:

As other have indicted, suppose you *do* strictly limit Exceptions to 
bad user inputs and other expected non-logic-errors. What happens when 
you forget to handle one of those Exceptions? That's a logic error that 
manifests as an uncaught Exception.

Code that handles and recovers from bad user input and other such 
"Exception" purposes is every bit as subject to logic errors as any 
other code. Therefore it is *impossible* to reliably ensure that 
Exception *only* indicates non-logic-errors such as bad user input. So 
the whole notion of strict separation falls apart right there. 
Exceptions are *going to* occasionally indicate logic errors, period. 
Therefore, they must carry enough information to help the developer 
diagnose and fix.

Is showing that diagnostic information to the user upon a crash 
unprofessional? Sure. But *all* crashes are unprofessional, so there's 
really no avoiding that. The *least* unprofessional crashes are the ones 
that 1. Don't get triggered more often than actually necessary 
(considering the given program domain.) and 2. Contain enough 
information to actually get fixed.



More information about the Digitalmars-d mailing list