should postconditions be evaluated even if Exception is thrown?

[Andrei Alexandrescu]

Rainer Deyke wrote:
> Andrei Alexandrescu wrote:
>> If a function throws a class inheriting Error but not Exception (i.e. an
>> unrecoverable error), then the postcondition doesn't need to be satisfied.
> 
> If an 'Error' is truly unrecoverable, then there's no point in treating
> it as an exception.  Just dump the core and get out.  The very existence
> of 'Error' suggests that recovery is possible, so the same rules should
> apply to 'Error' and 'Exception'.

Actually, it's not that bad. TDPL explains that in detail, but there are 
a number of guarantees given by the language even if you catch Error.

>> I just realized that postconditions, however, must be satisfied if the
>> function throws an Exception-derived object. There is no more return
>> value, but the function must leave everything in a consistent state. For
>> example, a function reading text from a file may have the postcondition
>> that it closes the file, even though it may throw a malformed file
>> exception.
> 
> Throwing an exception usually indicates a failure to reach the normal
> postcondition, but functions often have another postcondition that
> applies when the function terminates from an exception.  Common
> postconditions in the case of an exception include:
>   - The object is in a undetermined but valid state.  (The basic
> exception guarantee in C++ lingo.)
>   - The function has no side effects, i.e. all objects are in the same
> state as they were before the function was called.  (The strong
> exception guarantee.)

Yah, something like that.


Andrei