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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,ec21c3c7cdc7ff3e X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!130.59.10.21.MISMATCH!kanaga.switch.ch!news-zh.switch.ch!switch.ch!cernne03.cern.ch!cern.ch!news From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Handling invalid objects Date: Wed, 22 Mar 2006 17:42:53 +0100 Organization: CERN - European Laboratory for Particle Physics Message-ID: References: <3pKdnRGO2eWjQr3ZnZ2dneKdnZydnZ2d@comcast.com> <1peyefbqozdml.afdrxqiuyi0b$.dlg@40tude.net> <1c2j4h3onbhmk.p3uisoojg34b$.dlg@40tude.net> NNTP-Posting-Host: abpc10883.cern.ch Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sunnews.cern.ch 1143045772 275 (None) 137.138.37.241 X-Complaints-To: news@sunnews.cern.ch User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060203 Red Hat/1.7.12-1.1.3.4 X-Accept-Language: en-us, en In-Reply-To: <1c2j4h3onbhmk.p3uisoojg34b$.dlg@40tude.net> Xref: g2news1.google.com comp.lang.ada:3557 Date: 2006-03-22T17:42:53+01:00 List-Id: Dmitry A. Kazakov wrote: >>If by exception contracts you mean embedding the exception specification >>in the "signature" of the procedure/function, then it was already >>exercised by the Java community with rather disappointing effects. > > If Java did it wrong, let's do it right in Ada. Do what exactly? This is important question. The problem with exception specifications is that they are self-contradictory: - We use exceptions when we want to *DECOUPLE* error reporting from error handling. We find it especially good in those situations, where error reporting site and error handling site are separated by more than one level of subroutine calls (otherwise returning error codes is good enough). - We embed contract information in subroutine signatures to *COUPLE* the caller with the callee with respect to what they provide to each other and what they expect from each other. Now, "coupling" and "decoupling" are hardly compatible. Let's see where it breaks in so-called practice. First, there is a cascading effect when someone on one end of the chain adds a new exception type. Just let's say that the project evolved and for example a database got involved in something that was previously managed with the use of files. There is a new DBError exception, possibly having some db-specific information encoded (you know, exceptions are real objects in some languages :) ). This error is not handled neither by the offending function nor anybody in the chain, but is supposed to be handled at some higher level. In this scheme, the poor programmer has to add the DBError type to the exception specification to *all* functions in the chain. And apart from being a maintenance horror, it might be just impossible because the functions on the road are already closed or just owned by someone else. The tempting "solution" is to shut up the exception to meet the specification which was already cast in stone. Just grep any bigger Java project for things like: catch (Throwable e) {} // <- empty block here! to see it at work. Java guys can at least try to fight this problem with inheritance. The exception need not be exactly of the specified type, but might be something derived from what was specified. So, the other temptation is to specify the exception type that is rather general (higher in the inheritance hierarchy) to ease the accommodation of new exception types. But the more general is the specification, the less useful it is with regard to enforcing anything. In the extreme, it does not enforce anything at all. (Note that Ada would not have this possibility, or it would need to allow for exception hierarchies.) Second, the problem is that the error reporting and handling might be stated as a contract not between immediate caller and callee, but between some entities that operate across some other entity. A C++ example could be: void myFun() { vector array; // ... sort(array.begin(), array.end(), myComparator()); // ... } Above, the call chain is myFun->sort->myComparator, but the error handling and reporting is the business which is agreed between myFun and myComparator only. The sort algorithm was written long before myFun and myComparator and it (sort) does not care what it sorts and for whom. This means that sort should be completely transparent to the agreement that myFun and myComparator might have with regard to error reporting and handling. The solution might be to allow the compiler to synthesise the exception specs for sort automatically. But then, the specs would be just useless, because it would not enforce anything. The real problem is that languages based on simple subroutine calls are not appropriate for expressing these kind of relationships. Something fundamentally different would be needed to ensure that myFun handles exceptions from myComparator without involving sort in this process, but I don't see what that thing would look like. Anyway. The whole purpose of exceptions is to provide a kind of "out-of-band" channel which is *decoupled* from the main chain of subroutine calls. This "out-of-band" property is something that you either like (and/or accept) or not in the given project. Messing around with things like exception specifications is just swimming upstream - you cannot provide coupling into something that was *intended* to be "out-of-band" in the first place. Java guys failed with this exercise. C++ community dropped the idea altogether before failing (C++ never had compile-time enforcements of exceptions specs and today nobody's using them anyway). I don't see how Ada would do something like this without incurring effects described above or without fundamentally changing something in the way subroutines are used. But I'm looking forward to see your opinions on this (and maybe learn something about Ada culture? :) ). -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/