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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,f66d11aeda114c52 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,f66d11aeda114c52 X-Google-Attributes: gid103376,public From: "John G. Volan" Subject: Re: Building blocks (Was: Design By Contract) Date: 1997/09/15 Message-ID: <341D7EFA.3B60@ac3i.dseg.ti.com>#1/1 X-Deja-AN: 272741481 References: <5ulurp$aj8$1@miranda.gmrc.gecm.com> <5un58u$9ih$1@gonzo.sun3.iaf.nl> <5v0bph$n98$2@miranda.gmrc.gecm.com> Reply-To: johnv@ac3i.dseg.ti.com Organization: Raytheon TI Systems Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-15T00:00:00+00:00 List-Id: Robert Dewar wrote: > > The specific issue in Ada of whether it should be part of the syntax of > the language to specify the exceptions that can be raised is of course > one that was extensively discussed, and the quite deliberate decision was > made that it is unhelpful to require these to be stated in the syntax. > > The reason is that there are too many exceptions (Storage_Error, or the > various IO errors if any IO is done, or other application defined system > wide exceptions) which would be named all over the place and create clutter. > Note that Program_Error would also have to be named almost everwhere because > of the Access Before Elaboration (ABE) considerations. There are a couple of strategies that could be applied to this problem: (1) Take certain common language-defined exceptions as givens (e.g., Storage_Error, Program_Error, Constraint_Error). That is to say, assume that they are implicitly part of the interface of every subprogram/method, and don't require the programmer to explicitly list them. (2) Make exceptions first-class objects, and take advantage of class hierarchies to simplify subprogram/method interfaces. For instance, IO exceptions might be organized into a hierarchy rooted at some abstract IO_Exception class. A method could declare that it can raise any IO_Exception, without having to explicitly list all the subclasses. As I understand it, this is essentially the strategy Java uses. I must admit that I like being able to treat exceptions as first-class objects organized in class hierarchies, and I miss that capability in Ada95. I wonder why this notion didn't catch on in the Ada95 design ... is it because first-class exceptions would have introduced a so-called "distributed overhead" into the language? -- Internet.Usenet.Put_Signature (Name => "John G. Volan", Employer => "Raytheon/TI Advanced C3I Systems, San Jose, CA", Work_Email => "jvolan@ti.com", Home_Email => "johnvolan@sprintmail.com", Slogan => "Ada95: World's *FIRST* International-Standard OOPL", Disclaimer => "My employer never defined these opinions, so using " & "them would be totally erroneous...or is that just " & "nondeterministic behavior now? :-) ");