From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,db5c6b2ef47d4b9e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-06-22 08:15:21 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!howland.erols.net!netnews.com!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: short-circuit control forms Date: Fri, 22 Jun 2001 10:55:18 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9gvm8q$7ss$1@nh.pace.co.uk> References: <3B30F836.D700DAA3@raytheon.com> <3B312260.728686B5@boeing.com> <3B3143A2.89CC2841@easystreet.com> <3B320D90.DD4BB9B2@ftw.rsc.raytheon.com> <3B3216D9.113A612B@easystreet.com> <9gtfn7$dl9$1@nh.pace.co.uk> <3B332A96.64DDB78E@earthlink.net> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 993221722 8092 136.170.200.133 (22 Jun 2001 14:55:22 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 22 Jun 2001 14:55:22 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:9032 Date: 2001-06-22T14:55:22+00:00 List-Id: 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" 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