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!news3.google.com!news.glorb.com!npeer.de.kpn-eurorings.net!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> Date: Sat, 26 Mar 2005 13:36:36 +0100 Message-ID: <78nfet0wiu9o.oyhnnedi6wss$.dlg@40tude.net> NNTP-Posting-Date: 26 Mar 2005 13:36:29 MET NNTP-Posting-Host: 2af9437c.newsread2.arcor-online.net X-Trace: DXC=EKk_d`Z0VNO:BTg1DiO7HBQ5U85hF6f;DjW\KbG]kaMH]kI_X=5KeaFaXZofj4N On Sat, 26 Mar 2005 11:19:18 +0100, Ludovic Brenta wrote: > Robert A Duff writes: >> Well, actually, during the Ada 9X design I tried to push for a >> class-hierarchy of exceptions. I don't like every detail of the way >> C++ does it, but at least in *this* regard, it's better than Ada. >> >> Jerry Coffin is wrong that Ada does not allow attaching information >> to exception, by the way. Ada allows attaching Strings, which is >> admittedly a kludge. Using the class-hierarchy, as Jerry advocates, >> would be cleaner, and type safe. > > I kind of like Ada exceptions as they are now. Because one cannot > carry much information in them (apart from the kluge you mentioned), > one tends not to rely on them for the normal flow of operations. I > have seen Java programs that would rely on exceptions for all kinds of > things, leading to spaghetti code. In C++ I find it a bit odd that I > can throw and catch an entire hash table as an exception if I want to. > > The C++ way of catching all exceptions of a class and its derived > classes can lead to confusion. One can have multiple exception > handlers for the same exception and it may not be immediately obvious > to the reader which one is called. I see this as a maintenance > problem. > > Another concern of mine with exception classes is that they'd have to > be allocated on the heap. There are situations where there is no heap > to allocate from, or where dynamic allocation is forbidden. I think > it necessary to provide a simple exception mechanism that does not > require any dynamic allocation, much less dynamic dispatching. > > Perhaps a good middle-ground would be an addition to Ada along the > lines of: > > 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; > > Programs that want to carry rich information with exceptions would be > allowed to do so, while "pragma Restrictions (No_Dispatch)" or > "No_Dynamic_Allocation" would guarantee, to those interested, that no > such thing happens. > > I am aware that all this would require the compiler to provide two > exception mechanisms and two kinds of Exception_Occurrences, so I may > have opened a can of worms here. You had. (:-)) > Just thinking out loud :) A pair of simple questions: 1. Dispatching to non-existing methods of Extra_Information? 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. 3. Extra_Information should probably be controlled, what about finalization rules? 4. Two copies of Extra_Information if the exception was raised in a rendezvous? Protected type Extra_Information? (protected types are still untagged) 5. When and where Extra_Information gets deallocated? 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de