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,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!feeder.enertel.nl!nntpfeed-01.ops.asmr-01.energis-idc.net!feeder.xsnews.nl!feeder.news-service.com!tudelft.nl!transit0.news.tiscali.nl!tiscali!transit1.news.tiscali.nl!dreader2.news.tiscali.nl!not-for-mail Newsgroups: comp.lang.ada,comp.lang.c++,comp.realtime,comp.software-eng Subject: Re: Class hierarchy of exceptions (Ada, C++) 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> From: Ludovic Brenta Date: Mon, 28 Mar 2005 12:24:56 +0200 Message-ID: <87d5tkvzif.fsf@insalien.org> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) Cancel-Lock: sha1:Zu+0vw7XSPI+vzjfvr5luDR463c= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Tiscali bv NNTP-Posting-Date: 28 Mar 2005 12:25:05 CEST NNTP-Posting-Host: 83.134.239.98 X-Trace: 1112005505 dreader2.news.tiscali.nl 44084 83.134.239.98:36128 X-Complaints-To: abuse@tiscali.nl Xref: g2news1.google.com comp.lang.ada:10063 comp.lang.c++:47576 comp.realtime:1768 comp.software-eng:5400 Date: 2005-03-28T12:25:05+02:00 List-Id: "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. > 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. > 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. 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. > 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). > 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? -- Ludovic Brenta.