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
