Re: Ensuring postconditions in the face of exceptions

[Ludovic Brenta <ludovic@ludovic-brenta.org>]

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.  You'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.