Re: Handling invalid objects

[Maciej Sobczak <no.spam@no.spam.com>]

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<MyType> 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/