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!gandalf.srv.welterde.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: Tue, 25 Nov 2014 16:12:07 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <0d8452a9-68c9-4835-b6f3-17407132ca9f@googlegroups.com> <8194a204-7b15-463d-a2fd-4d3ba342fe97@googlegroups.com> <8f203a9a-6c7c-4614-bc7d-efa65bf10776@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1416953529 9964 24.196.82.226 (25 Nov 2014 22:12:09 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 25 Nov 2014 22:12:09 +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:23722 Date: 2014-11-25T16:12:07-06:00 List-Id: wrote in message news:8f203a9a-6c7c-4614-bc7d-efa65bf10776@googlegroups.com... >Of course I always listen seriously to Jeff Carter but it's not obvious to >me that doing >"C in Ada" is bad. It's bad. :-) > If I remember correctly Google employees are recommended to avoid using > exceptions >when doing C++. The designers of Google Go has gone great lengths to avoid >the exception >concept as much as possible. Very bad advice, IMHO. With one exception (pun intended): > In addition SPARK forbids usage of exceptions. While I think SPARK would be better served with limited exception support, at least they require a proof that no exceptions can be raised. The reason I feel so strongly about this is that exceptions (especially Constraint_Error and Program_Error) point out bugs in your code. Whenever you "eat" an exception (turning it into an error code, or simply ignoring it), you've put an opportunity to ignore a bug into your code. With all of the potential problems that entails. To take a concrete example. My web server runs with all exceptions enabled, and there is very little handling of exceptions (there are a few cases where expected exceptions are handled, as when a TCP/IP connection is unexpectedly dropped). Mainly, the worker tasks handle any surprise exceptions, log them, and reset everything in that task to a fresh state. Doing this prevents most bugs from causing security problems -- while a crafted input might cause one worker to fail, that only causes the sender to get no response. Other connections (workers) are uneffected, and there is almost no chance of a detected bug from overwriting memory or disk or any of the other things that cause security problems. Exceptions surely aren't enough to prevent all security issues, but they can help avoid a substantial number of them. (As previously noted, if you could prove that no exceptions are possible - meaning that no low-level bugs are possible - that would be better than having to figure out last-chance handlers and the like, but that's still beyond the state of the art for general purpose code. When that changes, I'll reconsider my stance on exceptions, but not until then.) Randy.