should postconditions be evaluated even if Exception is thrown?
Michel Fortin
michel.fortin at michelf.com
Fri Dec 4 04:07:36 PST 2009
On 2009-12-03 19:31:37 -0500, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> said:
> Michel Fortin wrote:
>> On 2009-12-03 17:16:11 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> said:
>>
>>> I found one more example.
>>>
>>> A function that transfers money from one account to another must
>>> provide a postcondition even in the case of failure: no matter what,
>>> upon exit, the sum of the monies in the accounts is preserved. The
>>> transfer itself may fail for any number of complex reasons (overdraft,
>>> limit of transfers per month reached, account has limited access etc.)
>>> but the transfer function must in all cases preserve the total sum of
>>> funds in the two involved accounts.
>>
>> That's a good example.
>>
>> But make this multithreaded and you have to hold the lock or
>> transaction across the function and its pre- and post-conditions. Where
>> should we stop?
>>
>
> I'd think the pre- and postconditions msut be under the lock anyhow.
That'll only work if the lock is acquired outside of the function call.
If the lock is acquired inside the function, pre- and post-conditions
cannot be under the lock, and thus cannot check that.
I think this just show that you probably ought to have two functions:
one acquiring the lock which calls the other one to do the actual
processing, the later one can have the pre-/post-conditions. But you
can't put a contract on the one acquiring the lock since the contract
would be outside it.
Well, you could avoid it if labeling the function with @synchronized
was sufficient, but for the case above you probably want two locks, or
some sort of database transaction, which won't work with @synchronized.
--
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/
More information about the Digitalmars-d
mailing list