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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7d3cb5920e882220 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Exceptions Date: Fri, 7 Dec 2007 21:30:05 -0600 Organization: Jacob's private Usenet server Message-ID: References: <5947aa62-2547-4fbb-bc46-1111b4a0dcc9@x69g2000hsx.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1197084394 18064 69.95.181.76 (8 Dec 2007 03:26:34 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 8 Dec 2007 03:26:34 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Xref: g2news1.google.com comp.lang.ada:18774 Date: 2007-12-07T21:30:05-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:uvkiadiwrfh2.wi288ebeq18y.dlg@40tude.net... ... > When "a way to force" reads "exceptions contract", then the answer is no, > there is no way, alas. The ARG has discussed "exception contracts" a couple of times, but there didn't seem that there was enough interest. The problem was mainly that they simply don't look very valuable (for Ada, I'm not going to comment on other languages) when the details are looked at, and they'd be fairly complex to define. The biggest issue is compatibility, of course (since Ada has had exceptions from the beginning, and never has had contracts, they'd have to be optional - but it's not clear if optional contracts are worth much). Another one is what to do if a contract is violated. The obvious answer of raising Program_Error doesn't do anything other than lose information about an exception, so that isn't very satisfying. (Static detection of contract violations isn't possible in general because the contracts have to be optional.) And then there is the problem of predefined exceptions like Storage_Error -- every routine *can* raise Storage_Error, although few *expect* to do so (if they don't allocate memory). Does that have to be included in every contract? If so, that's ugly, and if not, the oddity of not quite a contract is unpleasant. And there are more issues: the maintenance cascade when an exception is added or removed; what about call-back routines (think Process in the Containers library); and so on. I'm sure that something could be worked out, but it seemed like there were more valuable things to do. Randy.