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.
