Non-null objects, the Null Object pattern, and T.init

Walter Bright newshound2 at digitalmars.com
Fri Jan 17 17:46:56 PST 2014


On 1/17/2014 4:44 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang at gmail.com>" wrote:
> Big systems have to live with bugs, it is inevitable that they run with bugs.

It's a dark and stormy night. You're in a 747 on final approach, flying on 
autopilot.

Scenario 1
----------

The autopilot software was designed by someone who thought it should keep 
operating even if it detects faults in the software. The software runs into a 
null object when there shouldn't be one, and starts feeding bad values to the 
controls. The plane flips over and crashes, everybody dies. But hey, the 
software kept on truckin'!

Scenario 2
----------

The autopilot software was designed by Boeing. Actually, there are two 
autopilots, each independently developed, with different CPUs, different 
hardware, different algorithms, different languages, etc. One has a null pointer 
fault. A deadman circuit sees this, and automatically shuts that autopilot down. 
The other autopilot immediately takes over. The pilot is informed that one of 
the autopilots failed, and the pilot immediately shuts off the remaining 
autopilot and lands manually. The passengers all get to go home.


Note that in both scenarios there are bugs in the software. Yes there have been 
incidents with earlier autopilots where bugs in it caused the airplane to go 
inverted.

Consider also the Toyota. My understanding from reading reports (admittedly 
journalists botch up the facts) is that a single computer controls the brakes, 
engine, throttle, ignition switch, etc. Oh joy. I wouldn't want to be in that 
car when it keeps on going despite having self-detected faults. It could, you 
know, start going at full throttle and ignore all signals to brake or turn off, 
only stopping when it crashes or runs out of gas.


More information about the Digitalmars-d mailing list