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-Thread: 103376,703c4f68db81387d X-Google-Thread: 109fba,703c4f68db81387d X-Google-Thread: 115aec,703c4f68db81387d X-Google-Thread: f43e6,703c4f68db81387d X-Google-Attributes: gid103376,gid109fba,gid115aec,gidf43e6,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Class hierarchy of exceptions (Ada, C++) Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <4229bad9$0$1019$afc38c87@news.optusnet.com.au> <1110032222.447846.167060@g14g2000cwa.googlegroups.com> <871xau9nlh.fsf@insalien.org> <3SjWd.103128$Vf.3969241@news000.worldonline.dk> <87r7iu85lf.fsf@insalien.org> <1110052142.832650@athnrd02> <1110284070.410136.205090@o13g2000cwo.googlegroups.com> <395uqaF5rhu2mU1@individual.net> <1111607633.301232.62490@z14g2000cwz.googlegroups.com> <87oed6wvyx.fsf_-_@insalien.org> <78nfet0wiu9o.oyhnnedi6wss$.dlg@40tude.net> <87d5tkvzif.fsf@insalien.org> Date: Mon, 28 Mar 2005 14:29:36 +0200 Message-ID: <1ztttydl00c9.1o3ajufokqy8q.dlg@40tude.net> NNTP-Posting-Date: 28 Mar 2005 14:29:26 MEST NNTP-Posting-Host: 3141b3cb.newsread4.arcor-online.net X-Trace: DXC=egmdYg?]GCVfnCoe<@CEZ^:ejgIfPPldTjW\KbG]kaMXFYk:AnJB[C]>\QCE?GV9>X[6LHn;2LCV^COgUkn_?_Y_LUEPKAmD8U\ X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:10068 comp.lang.c++:47591 comp.realtime:1773 comp.software-eng:5407 Date: 2005-03-28T14:29:26+02:00 List-Id: On Mon, 28 Mar 2005 12:24:56 +0200, Ludovic Brenta wrote: > "Dmitry A. Kazakov" writes: >> Ludovic Brentawrites: > [...] >>> package Ada.Exceptions.Extra is >>> type Extra_Information is abstract tagged null record; >>> >>> procedure Raise_Exception (E : in Exception_Id; >>> Information : in Extra_Information'Class); >>> >>> function Exception_Information (X : Exception_Occurrence) >>> return Extra_Information'Class; >>> end Ada.Exceptions.Extra; > [...] > >> A pair of simple questions: >> >> 1. Dispatching to non-existing methods of Extra_Information? > > You'd have to "down-cast", which would raise Constraint_Error if the > Extra_Information was not of the expected type. What if Extra_Information is extended: type My_Extra_Information is new Extra_Information with private; procedure Say (Info : My_Extra_Information); At some non-library level Say gets overridden. Then this new object is attached to an exception which is propagated out of the scope of the override. A handler then makes a dispatching call to Say. What happens? One possible solution is to force the attached object to the base class when the child type gets out of scope. But then things become even more interesting, because Say might be abstract! Then object need to be partially finalized etc. That would be quite sort of C++! (:-)) Another solution is to route the exception to Program_Error when anything from My_Extra_Information gets out of scope. This would be bullet proof, but I don't believe many would enjoy it. >> 2. Accessibility rules for members of Extra_Information. Technically >> Extra_Information is a sort of result value. As such it requires special >> handling of all access values (pointers) it may do to local objects. > > I would say that the actual type (that extends Exra_Information) must > be visible in the exception handler and at the point of > Raise_Exception. But how would you check it? The exception handler knows nothing about any derived types. Yet it can dispatch ... to something that no more exists. >> 3. Extra_Information should probably be controlled, what about >> finalization rules? > > I hadn't thought about that. For the mechanism to be useful, I > suppose that finalization would have to occur at the end of the > exception handler. I thought about controlled components and pointers to controlled objects. They may get out of scope before a handler catches the exception. > However it may not be desirable that > Extra_Information be controlled, as this would make it possible for > Deallocate to raise an exception. >> 4. Two copies of Extra_Information if the exception was raised in a >> rendezvous? Protected type Extra_Information? (protected types are >> still untagged) > > The Extra_Information doesn't have to be protected, it can contain an > access to a protected object. This would make it quite easy to raise > two copies of it in two tasks. Also it will be two copies of Extra_Information? I definitely do not like it. This would mean that the behavior will vary depending on where exception was raised. I do prefer present by-value semantics of Ada model. But if it gets extended, and the direction is tagged types, then that is another semantics: tagged types are by-reference. The only possible logical consequence of this is that user-defined exception objects have to be protected. >> 5. When and where Extra_Information gets deallocated? > > I would say, at the end of the last exception handler (i.e. the one > that doesn't reraise the exception). OK that means that the mechanics will be pretty inefficient. Upon Raise_Exception, the object will always be copied. >> I think that before making any detailed proposals we should consider a >> contract model of exceptions. Points 1..5 might look very different if >> there were exception contracts. > > What do you have in mind? Let's consider a model based on [sub]types. If there are exception contracts then all possible exception types are known in each handler context. If you don't allow open-end things like exception'Class in contracts then there is nothing to surprise you in any handler. OK, that would probably be too rigid. We could relax it by allowing classes constrained to ranges of types: sort of type E1 is new exception with ...; ... type EN is new EN-1 with ...; procedure Foo exception E1'Class (EN) | Constraint_Error | ...; or procedure Foo exception E1..EN | Constraint_Error | ...; The point is that Foo knows what it will raise, the handler knows if the body may call Foo. Further Foo cannot raise anything defined within Foo. Same is applicable to any scope. If I try declare My_Exception is new exception; begin ... end; Then I'll get compile error telling that My_Exception may propagate out of the scope. declare My_Exception is new exception; Old_Style_Exception : exception; -- That's OK, no new type here begin ... exception when My_Exception => ... -- Alright now end; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de