Re: Ensuring postconditions in the face of exceptions

["Jeffrey R. Carter" <spam.jrcarter.not@spam.acm.org>]

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