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!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!198.186.194.251.MISMATCH!transit4.readnews.com!news-xxxfer.readnews.com!news-out.readnews.com!postnews3.readnews.com!not-for-mail Date: Sat, 08 Dec 2007 07:26:21 -0500 From: "Peter C. Chapin" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Exceptions References: <5947aa62-2547-4fbb-bc46-1111b4a0dcc9@x69g2000hsx.googlegroups.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <475a8d6d$0$30677$4d3efbfe@news.sover.net> Organization: SoVerNet (sover.net) NNTP-Posting-Host: ad5df729.news.sover.net X-Trace: DXC=odgG`6ZmW3?@`i3kGa5[ Randy Brukardt wrote: > The ARG has discussed "exception contracts" a couple of times, but there > didn't seem that there was enough interest... These sort of issues have also been discussed at length in the C++ community, mostly in the context of why C++'s exception specifications were a mistake. In those discussions I've heard many reasonable people also express the opinion that Java's statically enforced exception specifications were a bad idea. The problem often quoted is that there are cases where an exception looks like it could happen, but for reasons the compiler doesn't know can't actually happen. As a simple example consider the code fragment if Has_Acceptable_Value(X) then P1(X); P2(X); P3(X): end if; Suppose P1 raises an exception if X is negative. Depending on what Has_Acceptable_Value does, it is quite possible that can't happen in the code above. If you specify exception contracts the way Java did, then the programmer in the above case ends up having to handle an exception that won't happen or claim to propagate and exception that won't get propagated. Either option is undesirable. While one could argue that it is safest to assume the exception might happen anyway (since Has_Acceptable_Value might change or be incorrect), forcing empty handlers all over the place to cover such possibilities doesn't seem right either. In fact, such handlers would probably eat the unexpected exceptions and actually prevent buggy from being discovered and fixed. In this respect exception contracts might actually reduce reliability rather than promote it. C++ checks exception specifications at run time, but then it's hard to know what to do when a check fails. C++ throws a different exception in that case, but that doesn't really solve anything as far as I can see. The C++ community seems to have concluded that being able to declare a function as throwing no exceptions is potentially useful, but that there is little point in trying to go beyond that. It seems like Ada got this right by not attempting to provide language based exception contracts. Adding such contracts to Ada might well be taking the language in the wrong direction. Peter