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!news4.google.com!out04a.usenetserver.com!news.usenetserver.com!in01.usenetserver.com!news.usenetserver.com!news.tele.dk!news.tele.dk!small.news.tele.dk!fi.sn.net!newsfeed2.fi.sn.net!news.song.fi!not-for-mail Date: Tue, 11 Dec 2007 15:21:57 +0200 From: Niklas Holsti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20060628 Debian/1.7.8-1sarge7.1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Exceptions References: <5947aa62-2547-4fbb-bc46-1111b4a0dcc9@x69g2000hsx.googlegroups.com> <475c6ed8$0$13111$9b4e6d93@newsspool2.arcor-online.net> <1kxk3hlfa25dw$.fl2wvbn0tpbg$.dlg@40tude.net> <475d296a$0$27813$4f793bc4@news.tdc.fi> <12mjar2f2t2e6$.o2upq0n29j1f.dlg@40tude.net> <475d99c6$0$3520$4f793bc4@news.tdc.fi> <1x0h6yxp9rhy1.1thonmo9cmwy3$.dlg@40tude.net> In-Reply-To: <1x0h6yxp9rhy1.1thonmo9cmwy3$.dlg@40tude.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <475e8bde$0$27850$4f793bc4@news.tdc.fi> Organization: TDC Song Internet Services NNTP-Posting-Host: laku61.adsl.netsonic.fi X-Trace: 1197378527 news.tdc.fi 27850 81.17.205.61:32855 X-Complaints-To: abuse@tdcnet.fi Xref: g2news1.google.com comp.lang.ada:18896 Date: 2007-12-11T15:21:57+02:00 List-Id: Dmitry A. Kazakov wrote: > On Mon, 10 Dec 2007 22:02:55 +0200, Niklas Holsti wrote: > >>One reason for the large number of application-defined exceptions >>in this application may be that it uses a lot of functional-style >>programming with functions that return objects with run-time >>constraints (eg. unconstrained array types). Such functions cannot >>easily use error codes and must use exceptions to signal problems. > > I tend use End_Error, Use_Error, Data_Error in such cases. I don't like that at all, because in my mind End_Error etc. are associated with Ada IO, not with my application -- their meaning (semantics :-) is not appropriate, and I don't want to be Humpty Dumpty and make them mean what I want them to mean. Of course, if the function in question actually is reading a file, and fails because the file ends at an unexpected point, then End_Error could be appropriate. But for a function that has no connection with IO I would never "reuse" End_Error just to avoid declaring a specific exception. > The question is > how many different exceptions may propagate from a set of closures used in > one context. Not that many, so my guess is that one need not so many > different exceptions. But surely one of the main points of a contract is to show what a caller may have to do, to handle the propagated exceptions. To "overload" one exception (such as End_Error) with many different meanings, perhaps requiring different handling, would make the caller's job difficult. I agree that the number of different exceptions that are usefully propagated from most subprograms is generally small, because the caller does not have enough understanding of the possible exceptional situtations in the callee to be able to handle many different exceptions in specific ways. >>Clearly most subprograms have no exception >>handlers at all and thus propagate all exceptions raised in them or >>in their callees. > > Yes, this why I don't believe in the argument of abundant exception > handlers spoiling each and other program block. I don't see why contracts > should change anything here. I think all subprograms would need contracts (to specify the possibly propagated exceptions), not just the few subprograms that have exception handlers. The contract has to be in the subprogram declaration, while the presence or absence of exception handlers is a property of the body. Exception contracts could become a considerable part of the source code, especially if they would have to include the "always possible" exceptions like Storage_Error and in the absence of any SPARK-like analysis to exclude impossible exceptions from the contract. > A typical scenario: A lazy (let's say busy) programmer designs some set of > low-level primitives raising some exceptions. Then he starts to write a > middle layer that reuses those primitives, not necessarily in exactly this > order, but anyway. The exceptions of the middle layer are different, and of > course, the lower level exceptions do not propagate out the middle layer. > At this point he has already forgot most of when and what the lower level > raises. He remembers the exceptions E3 and E10, but the rest is vanished. > He decides whether to use "when others" but has no clear idea what to do > there, so maybe he places something looking more or less appropriate there > hoping that the debugging phase will shed more light on the issue, or just > drop it, depending on how much coffee he already had. The rest is obvious. > Does it sound familiar? Not really. I use informal exception contracts (in comments describing each and every subprogram), so I have not experienced that kind of mess. But I have mistakenly omitted a necessary handler once or twice, generally when the raise-to-handle distance has been very large (fatal or semi-fatal exception). > Now a contracted exceptions scenario: The programmer contracts a > middle-layer subprogram as non-propagating anything he does not want to. He > does not write any handlers, just compiles the code. The compiler complains > about E1. Aha - he says, where that E1 comes from? This repeats until all > low-level exceptions are caught, *understood* and handled. That would be ideal, and very much in the Ada spirit. But I can see why it is not an easy addition to Ada. >>The main problem I see in contracted exceptions is the problem with >>layered architectures where some intermediate layers are >>general/generic and not application-specific.... > > I think there is no simple answer to this. What could help IMO is: > > 1. Conditional exception contracts (for things like Storage_Error and > exceptions from the closures) > > 2. Inheritable exception contracts (to be able to refer to a group of > exceptions from another subprogram) > > 3. Making exceptions an ordered type with some kind of tree-like distance. > > 4. Renaming/delegation of exceptions. And perhaps also 5. Exceptions as formal generic parameters. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .