From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.236.40.41 with SMTP id e29mr12003988yhb.10.1417041509988; Wed, 26 Nov 2014 14:38:29 -0800 (PST) X-Received: by 10.140.92.176 with SMTP id b45mr45740qge.10.1417041509963; Wed, 26 Nov 2014 14:38:29 -0800 (PST) Path: border1.nntp.dca1.giganews.com!nntp.giganews.com!s7no2106071qap.1!news-out.google.com!m4ni578qag.1!nntp.google.com!s7no2106065qap.1!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 26 Nov 2014 14:38:29 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=24.197.113.215; posting-account=Ies7ywoAAACcdHZMiIRy0M84lcJvfxwg NNTP-Posting-Host: 24.197.113.215 References: <969708583438656051.436159nonlegitur-futureapps.invalid@reader80.eternal-september.org> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0d085a5a-d4ac-4506-ae5f-8da685f39004@googlegroups.com> Subject: Re: How to get nice with GNAT? From: brbarkstrom@gmail.com Injection-Date: Wed, 26 Nov 2014 22:38:29 +0000 Content-Type: text/plain; charset=ISO-8859-1 Xref: number.nntp.giganews.com comp.lang.ada:191062 Date: 2014-11-26T14:38:29-08:00 List-Id: 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.