Ensuring postconditions in the face of exceptions
in [ADA]
|
From: Jeffrey R. Carter on 15 Mar 2010 15:14 Ludovic Brenta wrote: > > 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. With your code, the only way an exception can be raised is if the input value of Dirty is True. Since Dirty is not a parameter of Visit, the call to Visit presumably doesn't change Dirty. If so, you could eliminate the exception handler and have the desired functionality: Dirty would be True on return if there were an exception, and False if there were not. I think this was mentioned before. Is there a reason this is not acceptable? -- Jeff Carter "Have you gone berserk? Can't you see that that man is a ni?" Blazing Saddles 38
From: Randy Brukardt on 15 Mar 2010 23:13 "Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message news:wcc7hpgckyy.fsf(a)shell01.TheWorld.com... > "Randy Brukardt" <randy(a)rrsoftware.com> writes: > >> For the record, I think you mean "limited record types". There are no >> requirements on how limited private types or record types that happen to >> be >> limited because of a limited component are passed. > > Well, that needs some clarification: for example, a record containing > a task is passed by reference, even if the record doesn't explicitly > say "limited". > > The point is, the compiler looks at the full types of everything > involved when deciding whether it must pass something by reference. > So "limited private" is irrelevant. I missed a word: I meant "explicitly limited record type" (that is one that contains the word "limited" in the record declaration). That and "tagged" are the only ways to *guarantee* that a record is passed by reference. Jeff Carter writes: >Really? ARM 6.2 seems to me to say that any limited type (a type whose full >view >is limited) is passed by reference. This explicitly includes a composite >type >with a component of a limited type. You suddenly added "full view" to this, and that's the crux of the problem: "limited" is a property of a view, while "by-reference" is a property of a type. (BTW, 6.2(7) is subtly broken, see AI05-0096-1 for details if you're Adam or want to know every possible detail. :-) The point is that there are many limited types that are not required to be passed by reference, including some record types that are limited. Also note that your statement here is also subtly wrong: a record type has to be passed by reference if it has a by-reference component -- not a limited component! A component of a limited private type would make the record limited but not necessarily by-reference (read the rules carefully again). Repeat after me: "limited" is a property of a view! It's not constant for a particular type! That's a common mistake that even those of us on the ARG make from time-to-time. Randy.
From: Robert A Duff on 16 Mar 2010 11:18 "Randy Brukardt" <randy(a)rrsoftware.com> writes: > "Robert A Duff" <bobduff(a)shell01.TheWorld.com> wrote in message > news:wcc7hpgckyy.fsf(a)shell01.TheWorld.com... >> "Randy Brukardt" <randy(a)rrsoftware.com> writes: >> >>> For the record, I think you mean "limited record types". There are no >>> requirements on how limited private types or record types that happen to >>> be >>> limited because of a limited component are passed. >> >> Well, that needs some clarification: for example, a record containing >> a task is passed by reference, even if the record doesn't explicitly >> say "limited". >> >> The point is, the compiler looks at the full types of everything >> involved when deciding whether it must pass something by reference. >> So "limited private" is irrelevant. > > I missed a word: I meant "explicitly limited record type" (that is one that > contains the word "limited" in the record declaration). That and "tagged" > are the only ways to *guarantee* that a record is passed by reference. That's still not quite right. A record that contains a task, protected, or a tagged component is passed by ref, even if the record is not explicitly limited. See RM-6.2. > Jeff Carter writes: >>Really? ARM 6.2 seems to me to say that any limited type (a type whose full >>view >>is limited) is passed by reference. This explicitly includes a composite >>type >>with a component of a limited type. ....with a component of a by-ref type. > You suddenly added "full view" to this, and that's the crux of the problem: > "limited" is a property of a view, while "by-reference" is a property of a > type. (BTW, 6.2(7) is subtly broken, see AI05-0096-1 for details if you're > Adam or want to know every possible detail. :-) The point is that there are > many limited types that are not required to be passed by reference, > including some record types that are limited. Right. Example: record containing a component of a limited private type, whose full type is scalar. > Also note that your statement here is also subtly wrong: a record type has > to be passed by reference if it has a by-reference component -- not a > limited component! A component of a limited private type would make the > record limited but not necessarily by-reference (read the rules carefully > again). > > Repeat after me: "limited" is a property of a view! It's not constant for a > particular type! That's a common mistake that even those of us on the ARG > make from time-to-time. I don't understand why the definition of "by reference" is subtly different from the definition of "immutably limited". - Bob
From: Adam Beneschan on 16 Mar 2010 15:00 On Mar 16, 8:18 am, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > > Repeat after me: "limited" is a property of a view! It's not constant for a > > particular type! That's a common mistake that even those of us on the ARG > > make from time-to-time. > > I don't understand why the definition of "by reference" is subtly > different from the definition of "immutably limited". Well, for one thing, the language defines what types are "immutably limited", but it doesn't completely define which types are "by reference"---the implementation decides that in some cases (6.2(11)). -- Adam
From: Robert Matthews on 16 Mar 2010 15:25
Jeffrey R. Carter wrote: > Ludovic Brenta wrote: >> >> 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. > > With your code, the only way an exception can be raised is if the input > value of Dirty is True. Since Dirty is not a parameter of Visit, the call > to Visit presumably doesn't change Dirty. If so, you could eliminate the > exception handler and have the desired functionality: Dirty would be True > on return if there were an exception, and False if there were not. I think > this was mentioned before. Is there a reason this is not acceptable? > By which I presume the code could be: generic with procedure Visit (Object : in out T); procedure Refresh (Object : in out T; Dirty : in out Boolean) is begin if Dirty then Visit (Object); Dirty := False; end if; end Refresh; Looks to be the simplest approach to me, though Bob Duff's suggestion of a Cache type may be a better abstraction. Robert Matthews |