On 9 October 2013 12:13, Cliff Green
First, I'm completely in the camp of "if you define a pre-condition and it is violated, don't throw an exception or otherwise change the undefined behavior to some sort of different execution path".
One of the arguments for throwing an exception (or related design) for logic errors is to aid in bug detection as well as provide a path for abnormal error recovery. Both of these are good, real-world considerations, but (to me) are separate from the DBC discussions.
When I say one should assert on a detected precondition failure, it's really shorthand for putting the system into a known state. A mission critical system, for instance, might do something vastly more complicated than aborting. I just don't see how throwing, which normally involves running code dependent on state, accomplishes this. Debug builds are a different story, as it is okay not to put the system in a known state; a deliberate tradeoff is made between that and the time it takes to set up and search for more bugs, along with the understanding that some of the subsequent bugs may be either be false positives or hidden due to continuing in an unknown state.
(BTW, a non-null pointer might not be a valid pointer - besides checking for null, should the library also check that the pointer is within a valid process data memory area?)
That still isn't enough, as memory corruption due to some other bug may cause an invalid but non-nullptr pointer. -- Nevin ":-)" Liber mailto:nevin@eviloverlord.com (847) 691-1404