CVS difference for ai12s/ai12-0017-1.txt

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0017-1.txt

--- ai12s/ai12-0017-1.txt	2012/01/26 06:49:21	1.1
+++ ai12s/ai12-0017-1.txt	2015/10/13 23:51:06	1.2
@@ -818,3 +818,121 @@
 
 ****************************************************************
 
+From: Tucker Taft
+Sent: Sunday, June 28, 2015  4:31 AM
+
+Here are two references to review as part of our discussion of exception
+specifications:
+
+    1) http://www.mindview.net/Etc/Discussions/CheckedExceptions
+    2) Do a google search for "c++ exception specification deprecated"
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, July 13, 2015  6:32 PM
+
+> Here are two references to review as part of our discussion of 
+> exception specifications:
+> 
+>     1) http://www.mindview.net/Etc/Discussions/CheckedExceptions
+
+This goes to a Doubleclick domain parking page!
+
+>     2) Do a google search for "c++ exception specification deprecated"
+
+That's hardly a "reference"!
+
+The first reference that comes up (Wg21 standards document N3051) states that
+the main problem with them was that they added runtime overhead (in that an
+exception not contracted gets converted to something else, rather than being
+statically illegal). Since we're proposing full compile-time checking, that
+surely doesn't apply to Ada. They also had issues with them in generics, which
+would not be a problem for Ada (as there would be a mechanism for propagating
+the contract for formal subprograms, just as we have to do for Global and
+Nonblocking).
+
+You (Tucker) have repeatedly worried about the transitivity problem with
+exception contracts (that a contract needs to handle any exceptions that
+routines it calls might propagate). It seems to me that those problems will
+occur for any sort of statically checked contract, including the ones that
+you've been championing (Global, Nonblocking). Indeed, I suspect that Global
+will be at least as bad as an exception contract.
+
+I find exception contracts important for reusable code (like language-defined
+libraries, Claw, etc.) where raising the wrong exception is likely to cause
+major problems for client code. OTOH, "normal" code probably shouldn't use
+exception contracts (or any other compile-time checked contracts, for that
+matter). That is, a lot of the reported problems are due to using such
+contracts in places where they shouldn't be used. (For C++ and Java, it also
+appears that the design of the contracts was wrong.) In most uses that I
+anticipate, changing an exception contract would be a substantial
+incompatibility for users, so that would happen only rarely (for example, in
+Claw, changing of any part of its specification requires careful
+consideration; it's not something to be done lightly; currently, any changes
+in the exceptions propagated would just be an undetected bug). Detection of
+changes in exception behavior is important for such uses. (I do expect that
+all compile-time checked contracts will be a pain in the neck when creating
+new code; the benefits are almost solely during the maintenance stage of
+programming, where uninitentional changes to the behavior of a routine can be
+detected rather than being a ticking time bomb for clients.)
+
+It also possible that the mechanism for including the exception contract of a
+called routine would mitigate the problems, as the contracts would
+automatically adjust in that case if the contract of the called routine
+changes. It might make sense for that mechanism to be allowed on any
+subprogram (the same goes for Global, BTW), in order that one isn't forced
+into using a generic just to get that mechanism.
+
+Anyway, is it possible to get some references that are actual links to
+something other than chat lists? I'm not much interested in the opinions of
+random commenters. (It would be like designing Ada based on
+comp.lang.ada threads. :-)
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Tuesday, July 14, 2015  11:15 AM
+
+I concur with Randy. The C++-rejection of exception contracts is irrelevant to
+the discussion. They rejected them mainly for performace reasons and rightly
+so, because these semantics of mapping uncaught exceptions to a single
+exception to ripple up the stack seems not worth a penny of investment. Quite
+unlike compile-time contracts.
+
+Now, compile-time contracts, too, have their own issues wrt transitivity and
+particularly wrt memory-full and similar errors that can pop up in arbitrary
+places. This is worth discussing, but mainly with Java, not C++ input.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, July 15, 2015  5:03 PM
+
+>>      1) http://www.mindview.net/Etc/Discussions/CheckedExceptions
+>
+> This goes to a Doubleclick domain parking page!  ...
+
+Weird.  Google is still linking to this page if you look up "Bruce Eckel
+Checked Exceptions".  Here is another article that is related, involving the
+designer of C# who chose to omit checked exceptions:
+
+   http://www.artima.com/intv/handcuffsP.html
+
+Here is a "stackoverflow" discussion of this topic:
+
+   http://stackoverflow.com/questions/613954/the-case-against-checked-exceptions
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, July 22, 2015  9:10 AM
+
+Here is one more data point on exception specifications.  Not too relevant, but
+Google forbids use of exceptions in C++ code.  Some of the rationale is
+interesting from a maintenance point of view:
+
+   https://google-styleguide.googlecode.com/svn/trunk/cppguide.html
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent