Re: How to get nice with GNAT?

[brbarkstrom@gmail.com]

On Wednesday, November 26, 2014 4:27:37 PM UTC-5, Randy Brukardt wrote:
> "Dmitry A. Kazakov"  wrote in s message 
> 
> ...
> > If exceptions were under a contract, the list of possible exceptions to
> > catch would be definite and quite small in most cases. So, actually, we
> > could disallow "when others" for all subprograms having an exception
> > contract and calling only such subprograms (statically).
> 
> The practical problem with exception contracts is that they encourage people 
> (especially coders rather than engineers) to "eat" exceptions rather than to 
> figure out what ought to be done with them (or better yet, redoing the 
> code/preconditions/predicates so they can't arise). That's the practical 
> experience with them in Java, and that has caused some ARG members to be 
> rather strongly against them. (Which is why they didn't make it into Ada 
> 2012.)
> 
> I personally find that misguided (because Ada is for engineers, not coders), 
> and I'll try again with them the next Ada amendment.
> 
> BTW, that's a problem with all statically cateogorization contracts. We're 
> looking at a potentially blocking cateogorization as part of the 
> parallelization effort. What happens there is that calling any routine that 
> is potentially blocking is illegal inside of a routine that is declared as 
> non-blocking. (And unlike exception contracts, there's no workaround). The 
> effect is that one has to change the status of lots of routines in order to 
> use the categorization. (At least for this particular categorization, Ada 
> already says which language-defined routines are potentially blocking, so 
> it's just a matter of putting that into aspects and pragmas as needed - no 
> arguments about whether Sin should be potentially blocking :-)
> 
> Even so, I think statically checked contracts and categorizations are going 
> to be important, because they eliminate bugs at the source (and thus 
> eliminate the need to worry about how to handle a substantial proportion of 
> errors).
> 
>                                        Randy.

I think it may be sensible to think of exceptions as contingent events
that we couldn't include in the original design because
a) we aren't omniscient
[as a subset of that] a1) we're building complex mechanisms that have
unexpected interactions between the parts
b) the environment in which the program operates changes in unpredictable
ways
As a result, we are nearly certain to discover unexpected events only after
we put the system into operation.

Maybe a sensible idea would be to see if we could agree on a ranking with
a small number of categories and try to suggest appropriate exception 
handling policies and strategies for each category.  For example,
a) nuisances: unexepcted events that have minor impact, such as user
input that has a mixed case character string when we really wanted all
upper case.  Maybe if a procedure detects this condition, it could change
all the lower case characters to upper case as part of the exception handling
without re-raising the exception.
b) unpleasantries: unexpected events that have some impact, but don't
warrant a system panic.  As an example, perhaps one user in a multi-user
Web site sends in a string that would overflow a buffer.  This could be
a malicious attack, which is serious, but if caught, the exception handler
could deep six the response after logging the string and the source.
c) emergencies: unexpected events that have major impact including system
failure.  These are probably the hardest to plan for.  I remember that we
had two instances of failure due to operator errors in bringing up one of
those large UPS's.  The failures were a year apart and the personnel were
the same.

I'll note that the exceptions already built into Ada fall into big
categories that are similar in intent to this suggestion.  What might
be useful is to extend the approach to smaller categories and then use
a list of these as a basis for design and procedural audits of systems.
Such a list could also be helpful as a "standardization" of the jobs
system maintainers might have to deal with.

I suppose the best one can do immediately after an  uncertainty causes
a serious exception is triage on the initial problem.  The language cannot 
be expected to handle all the ingenious idiocy of us humans.  Building a 
culture of careful design and rewarding thoughtful responses that reduce 
problems is probably the most sensible response - but it's hard.  Maybe
we need an organization like the National Transportation Safety Board
that has publicly accessible accident reports.  Alternatively, maybe there's
a role for system underwriters that could provide independent assessments
of the cost of dealing with various system failures. 

Bruce B.