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