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