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,6b1a1ed8b075945 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!club-internet.fr!feedme-small.clubint.net!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Allocators and exceptions Date: Wed, 12 Sep 2007 17:32:52 -0500 Organization: Jacob's private Usenet server Message-ID: References: <1189323618.588340.87180@o80g2000hse.googlegroups.com> <1189369871.672082.162750@50g2000hsm.googlegroups.com> <1189460936.295604.143720@r29g2000hsg.googlegroups.com> <1189502377.626510.172690@22g2000hsm.googlegroups.com> <1189601170.835400.72630@w3g2000hsg.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1189636197 28582 69.95.181.76 (12 Sep 2007 22:29:57 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 12 Sep 2007 22:29:57 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896 Xref: g2news2.google.com comp.lang.ada:1926 Date: 2007-09-12T17:32:52-05:00 List-Id: "Simon Wright" wrote in message news:m2ir6fobaz.fsf@mac.com... > Maciej Sobczak writes: > > > What should the constructor do *after* handling the exception? > > Leave the object half-baked? > > I'm not sure exactly what Stephe meant by 'propagate'. It certainly > seems a bad idea to allow a Constraint_Error to propagate > unhandled. But what would be wrong with dealing with the problem and > then raising an appropriate exception from the constructor? (even > Constraint_Error if gnat makes sense). Because Ada *requires* storage leakage in such cases (although some compilers ignore the language definition and finalize anyway). An allocated object cannot be finalized until it's *type* is finalized or until an Unchecked_Deallocation is called -- and an Unchecked_Deallocation is not going to be called if a constructor propagates an exception. So the (inaccessible) object is supposed to hang around for a long, long time. The "proper" way to handle this is to ensure that default initialize of an object never propagates an exception, and then wrap the allocator properly: type Access_T is access all T; procedure Free is new Unchecked_Deallocation (T, Access_T); function Alloc_Object (...) return Access_T is A_T : Access_T := new T; -- Default initialized. begin A_T.all := ; return A_T; exception when others => Free(A_T); return null; end Alloc_Object; But I'm not going to argue that this is an ugly and complex way of handling this. Randy.