Re: [boost] Looking for thoughts on a new smart pointer:shared_ptr_nonnull

Subject: Re: [boost] Looking for thoughts on a new smart pointer:shared_ptr_nonnull
From: Cliff Green (cliffg_at_[hidden])
Date: 2013-10-09 13:13:20

I'm going to add a tangential set of comments to this thread, which has 
evolved into discussions relating to design-by-contract (among other 
things).

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.

Every non-trival app has bugs in it, and every execution environment has 
many ways that execution can fail, whether due to software bugs or other 
problems in the environment. If there are fault-tolerant or 
high-availability requirements (and I've had a lot of these in my career, as 
well as working in environments where crashes are not that critical), this 
must be addressed at a macro / higher level. You cannot design and code for 
every possible path of failure in an environment, whether throwing 
exceptions or some other form of error detection and recovery.

This might involve process monitoring and restart - segment faults, divide 
by zero, illegal operation, etc. Or maybe hardware has failed or errored - 
disk is full, memory card has failed, etc - and a failover or hardware 
swap-out or cleanup must be performed. Or maybe just a graceful shutdown, if 
possible - log, cleanup, cleanly shutdown.

Adding additional design and code paths for application logic bugs 
complicates the code, and (obviously) still doesn't achieve 100% safety. 
Every divisor can be checked for non-zero in code before division, but the 
benefit eludes me. A stack dump could be generated, aiding in finding the 
offending code, but there's still no easy recovery other than "starting 
over", since the underlying design assumptions (preconditions) have been 
violated. "Starting over" might be exiting the thread or process and 
re-starting, or it could be a hardware trap that generates an exception that 
is caught at a high-level and goes through some other sort of "start over" 
logic.

Null pointer checks where the precondition is a valid non-null pointer 
follow the same logic.

(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?)

I have lots of opinions relating to software reliability (some formed by 
interacting with flight avionics software and the related validation 
processes and costs), but I don't want to wander any farther off topic than 
I already have.

Cliff