On 10 October 2013 17:12, Gavin Lambert <gavinl@compacsort.com> wrote:
On 10/11/2013 4:00 AM, Quoth Nevin Liber:
In general, destructors are written assuming the invariants of the class
hold on entry to the destructor.
And..? If the constructor of an object throws, its destructor is not invoked. So all destructors that are called should still have good invariants.
If everything is good, where did the bad null pointer come from?? More likely than not it is due to another (undetected) broken invariant. It's only if you *don't* throw from the constructor that you'll have a
problem, because now you *do* have an object with an invalid invariant.
It is up to the designer of the library to determine if passing parameters that make it impossible to set up the class invariant is reasonable or not. If it is reasonable, it is part of the contract, and no problem.
In order for what you say about stack unwinding to be true, you have to
assume that the null pointer isn't due to a broken invariant somewhere else. Where is your evidence that no other object or program invariants are broken?
Where is your evidence that they are?
The fact that a programming bug was detected is strong evidence that something is, in fact, broken.
Given that this must (by definition) be the first time that this particular pointer has been assigned to a "must be non null" smart pointer object, everything else higher up the call stack either must not be using the pointer or must be ok with the idea that it could be null, otherwise the problem would have been encountered earlier.
If it was okay with it being null, why did it pass it to the non-null smart pointer? It may have hit other undefined behavior much earlier than this. Like I said, you've detected a programming bug, but you have no idea how extensive the damage already is. Pretending there is no other damage is lousy risk analysis.
Data corruption is a far worse user experience.
Granted. But there shouldn't be any of that here, unless the programmer doesn't write their higher-level catch handler properly.
Could you please show us your universal catch handler that handles every possible programming error w/o aborting, including corruption that might happen during the stack unwinding? -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404