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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1592759aa83d0d45 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-29 02:15:11 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!headwall.stanford.edu!fu-berlin.de!uni-berlin.de!dialin-145-254-039-049.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Suggestion for Ada 200x - Interface inheritance Date: Thu, 29 May 2003 11:17:34 +0200 Organization: At home Message-ID: References: <0Pxza.699607$OV.652508@rwcrnsc54> <5ad0dd8a.0305240435.337d9373@posting.google.com> <5ad0dd8a.0305250612.ec54c23@posting.google.com> <3ED1039F.7010001@spam.com> <719Aa.14547$fT5.3595@nwrdny01.gnilink.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-039-049.arcor-ip.net (145.254.39.49) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1054199709 5897211 145.254.39.49 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:37979 Date: 2003-05-29T11:17:34+02:00 List-Id: Robert A Duff wrote: > Hyman Rosen writes: > >> Wesley Groleau wrote: >> > But that meant adding a throws clause to each of hundreds of files. >> >> 'Throws' clauses are a really bad idea, the more so because it seems >> so right on first appraisal. > > Throws clauses are a bad idea in Java, because they require scattering a > whole lot of useless exception handlers all over the place. Or else a > whole lot of useless throws clauses. But I don't think they're a > fundamentally bad idea; I think it would be possible to design a > language without those problems. > > One thing Java got right is that there are two kinds of exceptions: > For one kind, you want to declare "this procedure can raise X", > and force callers to either handle it or declare that they throw it. > For the other kind, you don't want to declare anything. I do not think it is a good idea. The set of exceptions is countable for any given program, I hope. (:-)) I would like to declare: f potentially raises what A, B, C may raise and also the exceptions W and V, but not the exceptions X, Y, Z. > One thing Java got wrong is the some of the exceptions are in the wrong > category. For example, all the streams operations can throw I/O > exceptions, even though streams are not necessarily tied to I/O. > If an open-file operation is designed to raise a file-not-found > exception, then I think it's reasonable to require the caller to handle > it (or reraise it). But a read-from-stream operation should not require > any extra mumbo-jumbo at the call site; it might not even be reading > from a file. > > I also think you should let the programmer decide which exceptions are > in which category. For example, an out-of-memory exception > (Storage_Error, in Ada) should, by default, not require any > declarations, since pretty-much anything can raise it. > But in an embedded system, you might want the compiler to prove that > out-of-memory can't happen. I envision a compiler that calculates (at > link time) a worst-case stack size for every procedure (including called > procedures). The programmer could say, "on entry to this procedure, > make sure there's enough stack space". If the procedure is recursive, > or declares something like: > > X: String(1..N); > > where N is not known, the "worst case" would be "the size of the whole > address space". But if you don't do those things, the "worst case" > could be reasonable, and the compiler could prove at compile time (link > time, really) that certain regions of code (perhaps the whole program) > do not run out of stack space. > > Consider also something like a generic iterator: > > generic > with procedure Action(X: Element); > procedure Set_Iterate(S: Set); > -- Calls Action once for each element of the Set. > > Presumably Set_Iterate can raise whatever exceptions are raised by the > actual procedure passed to Action. But you don't want to say > Set_Iterate raises "any exception". You want to say, "Set_Iterate > raises whatever exceptions are raised by Action". That's not known at > compile time of the generic, but it could be known at compile time of > the instantiations. > > So for "throws clauses" to work well, we need some sort of pass-through > concept -- "this throws what that throws". This would allow abstraction > layers that simply pass exceptions through to avoid saying "throws > anything" and the subsequent clutter in clients. This is a simple inheritance model. A derivant inherits the contract which includes "throws clauses". It may strengthen it by saying "I will not throw X". Then the implementation of derivant has to catch X. > Another point is that most exceptions are really preconditions. Of course. > See > Eiffel, and design-by-contract. You want to declare not only that this > procedure raises Queue_Empty_Error, but also under what conditions that > exception is raised (e.g. if Is_Empty is True), and that > Queue_Empty_Error gets raised before modifying the queue. > > And if you have pre- and postconditions, I think you want to attach > postconditions to exceptional situations. You want a way to express, > "If this procedure returns normally, then such-and-such is true. If it > raises File_Not_Found, then so-and-so is true. And if it raises > Storage_Error, all bets are off (i.e., any data touched by this > procedure might have been damaged, so don't touch it)." Semantics of exceptions as a part of the contract, I like it. Of course, "throw clauses" has to be inherited with pre- and postconditions upon exceptions. Then a derivant may tune those. If it promises not to raise an exception then it is same as to say that the precondition of the exception is False. > And finally, you want user-settable defaults. Like, "All procedures in > this package, and all of its descendants, behave such-and-such a way in > the presence of so-and-so exception." -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de