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 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!matrix.darkstorm.co.uk!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: How to get nice with GNAT? Date: Wed, 26 Nov 2014 15:27:35 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <969708583438656051.436159nonlegitur-futureapps.invalid@reader80.eternal-september.org> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1417037256 27733 24.196.82.226 (26 Nov 2014 21:27:36 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 26 Nov 2014 21:27:36 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:23753 Date: 2014-11-26T15:27:35-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:g70ue0kjz9qi$.1b2fj6sqtjbez$.dlg@40tude.net... ... > 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.