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
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"
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk