Re: short-circuit control forms

["Marin David Condic" <marin.condic.auntie.spam@pacemicro.com>]

Exception handlers can definitely be used to sweep problems under the rug.
When I was building a rocket engine control where failure was not an option,
we only had exception handling at the outer-most control loops because if an
exception got to that point, you were either going to reboot the box
(possibly in mid-burn and blow the mission) or you were going to try to
ignore whatever caused it and press on hoping that the control would do
something reasonable to keep the rocket going. Naturally, we logged any
occurence of any exception in memory and could monitor this via test
monitoring equipment and telemetry. I'm pleased to say it never came up as
an issue - we never had an exception - but it *could* have masked a real
problem during testing. (Of course, for efficiency, we had to turn off most
runtime checks, but that didn't mean you couldn't get any exceptions - or
that this was the best way to build software. I'd have liked to leave the
checks in so we'd know if there were problems in the code, rather than let
them get into the field, but compromises must be made sometimes.)

MDC
--
Marin David Condic
Senior Software Engineer
Pace Micro Technology Americas    www.pacemicro.com
Enabling the digital revolution
e-Mail:    marin.condic@pacemicro.com
Web:      http://www.mcondic.com/

"Marc A. Criley" <mcqada@earthlink.net> wrote in message
news:3B332A96.64DDB78E@earthlink.net...
>
> The original version of a shipboard weapon control system I worked on
> had myriad exception handlers and checks for conditions that should not
> have been able to occur, but did, and so were trapped and worked
> around.  Needless to say, with the root causes left unaddressed, over
> time the system's operation got more and more corrupt and degraded,
> until it finally couldn't hold up any more, and would just lock up or
> crash.
>
> In the redesign of that system, exception handlers were permitted only
> for those exceptions whose raising was anticipated as part of "normal"
> failure operations.  And work-arounds to handle anomalous occurrences
> were strictly barred.  As a result, the system under development crashed
> more frequently than the extensively band-aided one it was going to
> replace.
>
> This caused consternation amongst program management, because they
> thought the redesigned system was supposed to be better than the
> original.  At the last presentation I made to the customer I explained
> why we were getting the crashes:  We were finding the bugs _now_,
> instead of following the previous practice of having the test group
> uncover them and send problem reports back through a longer analyze and
> fix cycle.  Our streamlined fix/test process was turning around bug
> reports in a day.  And instead of patching and hoping it would hold
> through test, we were getting close to having a twisted view of system
> crashes--we almost liked them, because it flushed out another bug and we
> had scads of log data available to quickly zero in on and fix the
> problem.
>
> When we delivered the system a few weeks later, there was only one
> low-priority bug report open against the system, and it was an order of
> magnitude better in performance, reliability, and understandability than
> its predecessor.
>
> Marc A. Criley
> Senior Staff Engineer
> Quadrus Corporation
> www.quadruscorp.com