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'. > 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.) -- Rainer Deyke - rain...@eldwood.com
