>Whether you do or don't use exceptions, it's far from a bad idea for objects to always check their internal consistency on entry from external callers.
That's a bad idea because of a several reasons. All reliable systems should be built on the idea of invariants and contracts. The violation of the contract/invariant should be treated as a fatal error.
So putting "assert(someInvariantState==43)" in method's body is fine as a purely debugging tool to find programmer's error. However, doing "if (someInvariantState!=42) return -ERR;" is a big NO-NO.
>As for dealing with errors in clean up, remind me again how exceptions improves on that? Would you throw an error from a destructor?
C++ doesn't have a nice solution for that. Java has one in the form of nested exceptions - it's possible to replace the current exception with the new one, retaining the current one as a nested exception.