Re: Ada 2012 Constraints (WRT an Ada IR)

[Robert Eachus <rieachus@comcast.net>]

On Monday, December 5, 2016 at 6:09:42 AM UTC-5, Simon Wright wrote:

> >>> I would consider it a major bug to have a pragma Assert that could
> >>> fail at run-time absent a hardware failure or some such. (Even though
> >>> it would be turned off in production code.)
> 
> Yes. Though it's really up to the system engineers to decide on system
> behavior in the presence of software failure.

I picked this since it quotes me, rather than to pick on Simon.  The important thing that is getting missed in this discussion is that there are lots of uses for software.  I spent most of my career working on software for radars, planes, and missiles, where production software means the stuff that flies--or gets installed on a mountain with no software or system engineer in easy reach.

Sometimes that means that crashing the software (well a controlled crash that turns off the radar then restarts from the beginning) is the right safety feature.  But in an aircraft you leave it to the pilot to shut the engines down.  Yes, the engine might be about to tear itself into little pieces in five minutes--but this may be the only working engine that will get you to the airport.  I remember one incident where the mechanic didn't put the o-rings on the (new) oil plugs.  The pilot shut down the center engine for low oil pressure, and headed back to Palm Beach.  Then the other two engines had oil pressure warnings.  He ran them as long as possible, glided until just above the waves--and restarted the center engine.  Safe landing, barely.

But notice that the cockpit crew should never end up fighting the software warning system.  If it doesn't help, cut the warning.  Read about what happened to the Quantas A380, when an engine failed and cut some of the wires in the wing.  Telling the cockpit crew IN THE AIR that thus and so is not reporting every few seconds is NOT helpful. On the ground?  Fine, if it is a deadline issue. (Hmm.  Not clock deadlines, deadlines as in the plane won't fly.)

Why do I remember such incidents?  And why did I consider it important for me to know about them.  It all comes back to this issue.  Who are your diagnostics and exceptions expected to help?

To bring it back here, as far as I am concerned, the Assert feature makes it easier to insure that debug only code does not end up causing real accidents.  Exceptions often need to be handled in production code, but such exceptions should usually be wrapped closely in specific handlers.

Oh, and that handler around one line might as well say "when others."  There may be some code you don't see that could result in an unexpected exception, say "Device_Error" not "Use_Error" when reading from a file, but the behavior to deal with it is the same.