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,c80e6f742e73478f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!d2g2000yqa.googlegroups.com!not-for-mail From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: Ensuring postconditions in the face of exceptions Date: Mon, 15 Mar 2010 02:14:44 -0700 (PDT) Organization: http://groups.google.com Message-ID: <3782da9f-3f92-455e-ac1c-7cab721fc4df@d2g2000yqa.googlegroups.com> References: <820d96c0-5d67-4b8c-8c5b-811ca4f1127e@g26g2000yqn.googlegroups.com> <8990d686-f703-4e9c-91b7-32410289983d@g11g2000yqe.googlegroups.com> <87ljdv56gy.fsf@ludovic-brenta.org> <5f3f45c6-0202-4a67-8517-182afaf7dceb@c16g2000yqd.googlegroups.com> NNTP-Posting-Host: 153.98.68.197 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1268644484 26238 127.0.0.1 (15 Mar 2010 09:14:44 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 15 Mar 2010 09:14:44 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: d2g2000yqa.googlegroups.com; posting-host=153.98.68.197; posting-account=pcLQNgkAAAD9TrXkhkIgiY6-MDtJjIlC User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8,gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.ada:10540 Date: 2010-03-15T02:14:44-07:00 List-Id: Alex Mentis wrote on comp.lang.ada: > Well, I'm not sure I'm suggesting you raise extra exceptions, just > handle them in the calling subprogram instead of the called > subprogram. =A0You're already re-raising the exception with the called > subprogram exception handler: The problem with that approach is that the processing of the Dirty flag is no longer localized in the Refresh procedure which, in fact, might as well disappear altogether; instead, each caller of Refresh (or Visit) must now remember to handle exceptions and reset Dirty to True accordingly. So let me summarize the various suggestions so far: (1) pass Dirty as "access" instead of "in out": works but, as you nicely put it, "One of the nice things about Ada over other languages is that you generally shouldn't have to worry about whether a parameter is copy-by-value or copy-by- reference." (2) pass Dirty encapsulated in a limited record: also works but this is even worse (IMHO) than "access" because it obscures the purpose of the limited record type. I'd have to have 10 lines of comments just to explain why there is a limited record type containing a single Boolean component. (3) make Dirty part of the object type T: the flag is necessary in only one of the places where T is used; also T is serialized in several places, so changing it is not a good idea. (4) handle the exception in the caller: there is no longer a central place for handling the Dirty flag therefore future maintenance is harder. As a side effect, the procedure Refresh loses most of its purpose, so might as well disappear. I came up with (5): place both Dirty and the Object to be visited in a record type and pass an access value to that record. This is a variation of (1); it is still ugly (IMHO) but the record type and the access-to-record type already existed so the change to the code base was minimal. Since, however, the existing record type contains many other things besides the Object and Dirty flag, the procedure Refresh receives much more information than it really needs, which might break encapsulation. All in all, no solution so far is as elegant as I would have liked but thanks anyway for the various suggestions. I think that (1) is still the least ugly though. -- Ludovic Brenta.