Null references redux

Justin Johansson procode at adam-dott-com.au
Sat Sep 26 18:35:12 PDT 2009


Walter Bright Wrote:

> bearophile wrote:
> > Walter Bright:
> > 
> >> I used to work at Boeing designing critical flight systems.
> >> Absolutely the WRONG failure mode is to pretend nothing went wrong
> >> and happily return default values and show lovely green lights on
> >> the instrument panel. The right thing is to immediately inform the
> >> pilot that something went wrong and INSTANTLY SHUT THE BAD SYSTEM
> >> DOWN before it does something really, really bad, because now it is
> >> in an unknown state. The pilot then follows the procedure he's
> >> trained to, such as engage the backup.
> > 
> > Today we think this design is not the best one, because the pilot
> > suddenly goes from a situation seen as safe where the autopilot does
> > most things, to a situation where the pilot has to do everything. It
> > causes panic.
> 
> I've never seen any suggestion that Boeing (or Airbus, or the FAA) has 
> changed its philosophy on this. Do you have a reference?
> 
> I should also point out that this strategy has been extremely 
> successful. Flying is inherently dangerous, yet is statistically 
> incredibly safe. Boeing is doing a LOT right, and I would be extremely 
> cautious of changing the philosophy that so far has delivered 
> spectacular results.
> 
> BTW, shutting off the autopilot does not cause the airplane to suddenly 
> nosedive. Airliner aerodynamics are designed to be stable and to seek 
> straight and level flight if the controls are not touched. Autopilots do 
> shut themselves off now and then, and the pilot takes command.
> 
> Computers control a lot of systems besides the autopilot, too.
> 
> 
> > A human needs time to understand the situation and act
> > correctly. So a better solution is to fail gracefully, giving back
> > the control to the human in a progressive way, with enough time to
> > understand the situation. Some of the things you have seen at Boeing
> > today can be done better,
> 
> Please give an example. I'll give one. How about that crash in the 
> Netherlands recently where the autopilot decided to fly the airplane 
> into the ground? As I recall it was getting bad data from the 
> altimeters. I have a firm conviction that if there's a fault in the 
> altimeters, the pilot should be informed and get control back 
> immediately, as opposed to thinking about a sandwich (or whatever) while 
> the autopilot soldiered on. An emergency can escalate very, very fast 
> when you're going 600 mph.
> 
> There have been cases of faults in the autopilot causing abrupt, bizarre 
> maneuvers. This is why the autopilot must STOP IMMEDIATELY upon any 
> fault which implies that the system is in an unknown state.
> 
> Failing gracefully is done by shutting down the failed system and 
> engaging a backup, not by trying to convince yourself that a program in 
> an unknown state is capable of continuing to function. Software simply 
> does not work that way - one bit wrong and anything can happen.
> 
> 
> > there's some progress in the design of
> > human interfaces too. That's why I suggest you to program in dotnet
> > C# for few days.

Re:
> As I recall it was getting bad data from the 
> altimeters. I have a firm conviction that if there's a fault in the 
> altimeters, the pilot should be informed and get control back 
> immediately, as opposed to thinking about a sandwich (or whatever) while 
> the autopilot soldiered on.

Walter, in the heat of this thread I hope you haven't missed the correlation with discussion
on "Dispatching on a variant" and noting:

"Further, and worth mentioning given another raging thread on this forum at the moment,
it turns out the ensuring type-safety of my design means that NPE's are a thing of the
past (for me at least).  This is due to strong static type checking together with runtime type
validation all for a pretty reasonable cost."

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=96847

Regards
Justin Johansson





More information about the Digitalmars-d mailing list