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,6b1a1ed8b075945 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!tiscali!newsfeed1.ip.tiscali.net!news.tele.dk!news.tele.dk!small.news.tele.dk!lnewsinpeer00.lnd.ops.eu.uu.net!bnewsinpeer00.bru.ops.eu.uu.net!emea.uu.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Allocators and exceptions Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.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: <1189323618.588340.87180@o80g2000hse.googlegroups.com> <1189369871.672082.162750@50g2000hsm.googlegroups.com> <1189460936.295604.143720@r29g2000hsg.googlegroups.com> <1189502377.626510.172690@22g2000hsm.googlegroups.com> Date: Tue, 11 Sep 2007 14:27:45 +0200 Message-ID: <5rjahxfvhazu.bol1ilmh6uew$.dlg@40tude.net> NNTP-Posting-Date: 11 Sep 2007 14:22:34 CEST NNTP-Posting-Host: 6c3e1600.newsspool3.arcor-online.net X-Trace: DXC=46kRS@3RMaQcHPTNZh_e7QMcF=Q^Z^V3X4Fo<]lROoRQ^;5]aA^R6>RQnZ4]YKj=dX[6LHn;2LCV^7enW;^6ZC`TIXm65S@:3>_[cb\nFG\Xb] X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:1887 Date: 2007-09-11T14:22:34+02:00 List-Id: On Tue, 11 Sep 2007 02:19:37 -0700, Maciej Sobczak wrote: > On 11 Wrz, 11:16, "Dmitry A. Kazakov" > wrote: > >>>>> P.S. Exceptions in constructors is a bad idea. >> >>> No, it's a very good idea. Otherwise you have to deal with half-baked >>> objects, which is Even Bigger Mess (tm). >> >> This is what you get when the exception is propagated out of a constructor. > > In this case I want the constructor to be rolled back. > Without exceptions (and rollback) the only option for handling errors > in initialization of (sub)components is to leave them half-baked. > When I create a new object and there is some error on the way, I want > to consider the object as if it never existed. This error is likely unrecoverable, so you have to reconsider your design which allowed such errors. BTW, formally everything is exactly as you wished! Observe, that new T(-5) creates an object of the type T_Access. This object does not come to existence and the compiler carefully eliminates any traces of this object. Everything is fine! What you actually want, but didn't say it, is that T_Access would take care of the things it points to, so its constructor (new) would. That is not what access types in Ada can. You want abstract access types. And this is the core of the problem. Ada does not have abstract interfaces for built-in types, alas. > This is what allows me to keep abstractions and invariants: either I > have the complete object with its guaranteed invariants, or there is > nothing. Anything in between is mess. This is violated upon aggregation of initialized components with side effects. I don't argue that this is good, I only state that this is the current language design and that it would be quite challenging to alter. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de