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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e646052dc594401f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews.google.com!z8g2000yqz.googlegroups.com!not-for-mail From: Claude Newsgroups: comp.lang.ada Subject: Re: Strategies with SPARK which does not support exceptions Date: Wed, 23 Jun 2010 20:24:02 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <93966134-a285-41c5-a7f6-8c59151718a7@k39g2000yqb.googlegroups.com> NNTP-Posting-Host: 70.79.53.248 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1277349842 28558 127.0.0.1 (24 Jun 2010 03:24:02 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 24 Jun 2010 03:24:02 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: z8g2000yqz.googlegroups.com; posting-host=70.79.53.248; posting-account=WPcl4AoAAAC3CTqLAgWnftzSSCqiCJ4J User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3,gzip(gfe) Xref: g2news1.google.com comp.lang.ada:11909 Date: 2010-06-23T20:24:02-07:00 List-Id: On Jun 23, 9:22=A0am, Warren wrote: Exceptions are not the best way to process error. (i.e., Not just a SPARK topic). > The downside of exceptions though, is that it requires > extensive testing to provoke them (or to prove they > don't occur). =A0So in a life-critical application, there > may be the requirement that it not throw its hands in > the air and give up (per exception). On the other hand, > proceeding incorrectly may be equally disastrous. > > So my point is that there are two valid approaches and > that "one size does not fit all". > > Warren Warren, you got quite the point, proceeding incorrectly may be disastrous. But not equally, because when the exception handler doesn't proceed correctly and gets another exception, what's going to happen next? Getting a third exception in a row, and so on ... Processing anything within an exception handler is not recommended. (That can even requires extra procedures to correct state/data which could become out of context/visibility). Safety critical system won't like any exception... That's one of the SPARK advantage, it can assess about the absence of run-time errors. But about operational hazards, that's another story (worst: the semantic responses are used to be generic!) Claude Defour