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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,61e9062c1f23b9d5 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!newsfeed.freenet.de!news.tiscali.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: contracted exceptions Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1181165630.012508.55290@i38g2000prf.googlegroups.com> <19fxsxv1god43$.1pqq8vgfu2itn$.dlg@40tude.net> <1it2vtizha2fi$.jxnoaxmm9sop$.dlg@40tude.net> <12vqux55uf5rn.1u5enj1mh0ubk$.dlg@40tude.net> Date: Sun, 10 Jun 2007 11:21:25 +0200 Message-ID: NNTP-Posting-Date: 10 Jun 2007 11:21:04 CEST NNTP-Posting-Host: 0a2912ae.newsspool3.arcor-online.net X-Trace: DXC=V78^\DPYfP:LNKYb?b>076McF=Q^Z^V384Fo<]lROoR1Fl8W>\BH3Y2?P2N8WQ]`>?DNcfSJ;bb[5IRnRBaCd?ndP?GLeX32GA255L=M5=; X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:16143 Date: 2007-06-10T11:21:04+02:00 List-Id: On Sat, 09 Jun 2007 22:04:24 +0100, Simon Wright wrote: > "Dmitry A. Kazakov" writes: > >> On Sat, 09 Jun 2007 13:32:59 +0100, Simon Wright wrote: > > I was trying to make the point that some restraints on program > legality can be made in the language by defining constrained types, > others you're stuck with hand-coded checks: > > pragma Assert ({correct calling sequence}, "bad calling sequence"); > > or if you prefer > > if not {correct calling sequence} then > raise Use_Error; > end if; > > All much of a muchness in terms of trying to make sure that the > program is correct and is used correctly. That's OK. My point is that raising Use_Error is a correct behavior of the program. It is not a bug. Therefore it has to be documented: "when the sequence is not this and that, then Use_Error is propagated." Such sequences are legal sequences, like an illegal Ada program is a legal input for an Ada compiler. Therefore the caller has to have a handler for Use_Error or else document it, etc. This is why exceptions should be contracted and not considered as "oops, we didn't think about this." > Also, this check is about a precondition, if the caller violates the > precondition she has no right to expect me not to raise unheralded > exceptions! Oh my. "If you don't do that, then I ..." (:-)) No, if the precondition was violated by the caller, then how this caller is supposed to handle the exception it does not know? And why would you rely on this handling, provided that it is exactly one who first violated the contract? If I designed pre-/postcondition/invariant stuff for Ada, then I would consider implementation of all run-time checks in an independent task with own stack. A violation would immediately about the monitored task, and the exception would be propagated in the monitor task. >> The contract would be a lie. Another reason is that you could not >> handle Baz, because that would change the program behavior with and >> without assertions checked. IMO run-time assertions is an utterly >> wrong idea. > > As I said before, I see little difference between assertions & > predefined language checks in terms of where they should be > used. Clearly you shouldn't use an assertion where the thing being > checked is legitimate failure behaviour! > > pragma Assert (not Vessel_On_Firing_Range); > Start_Test_Missile_Firing; Wasn't it an anti-vessel missile?... (:-)) Yes this is what I meant. The above would be legal, and people would use it, no matter what guidelines say. > Of course you can suppress (some) language-defined checks, but then > you get undefined bahaviour at run time if the error condition > happens. Is it worse to get unexpected exceptions or to compute with > out-of-range data? It is same, without any assumptions about the nature of the error. These assumptions cannot be reasonably made for unknown in advance errors. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de