Re: Exceptions

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 10 Dec 2007 22:02:55 +0200, Niklas Holsti wrote:

> One reason for the large number of application-defined exceptions 
> in this application may be that it uses a lot of functional-style 
> programming with functions that return objects with run-time 
> constraints (eg. unconstrained array types). Such functions cannot 
> easily use error codes and must use exceptions to signal problems.

I tend use End_Error, Use_Error, Data_Error in such cases. The question is
how many different exceptions may propagate from a set of closures used in
one context. Not that many, so my guess is that one need not so many
different exceptions.

> Clearly most subprograms have no exception 
> handlers at all and thus propagate all exceptions raised in them or 
> in their callees.

Yes, this why I don't believe in the argument of abundant exception
handlers spoiling each and other program block. I don't see why contracts
should change anything here.
 
>> This is IMO a question of custom and also of the language design. When
>> exceptions tend to propagate out of the application, one would certainly
>> like to make them "meaningful" indicating the fault reason as precise as
>> possible.
> 
> Yes, but whatever one does, an exception occurrence is almost never 
> meaningful for the user, only for the developer.

Right.

>> This is not what I wanted from Ada. I'd like to have all
>> exceptions handled. So I treat them rather as signals within and for the
>> application.
> 
> If I can foresee a situation that can cause a certain exception, of 
> course I put in a handler. The problem is programming errors or 
> input errors that I do not foresee. For such I still rely on 
> catch-all handlers at certain levels and ask the user to send me 
> the error messages that these handlers emit.

Which is one of the advantages of the contracted model.

A typical scenario: A lazy (let's say busy) programmer designs some set of
low-level primitives raising some exceptions. Then he starts to write a
middle layer that reuses those primitives, not necessarily in exactly this
order, but anyway. The exceptions of the middle layer are different, and of
course, the lower level exceptions do not propagate out the middle layer.
At this point he has already forgot most of when and what the lower level
raises. He remembers the exceptions E3 and E10, but the rest is vanished.
He decides whether to use "when others" but has no clear idea what to do
there, so maybe he places something looking more or less appropriate there
hoping that the debugging phase will shed more light on the issue, or just
drop it, depending on how much coffee he already had. The rest is obvious.
Does it sound familiar?

Now a contracted exceptions scenario: The programmer contracts a
middle-layer subprogram as non-propagating anything he does not want to. He
does not write any handlers, just compiles the code. The compiler complains
about E1. Aha - he says, where that E1 comes from? This repeats until all
low-level exceptions are caught, *understood* and handled.

> The main problem I see in contracted exceptions is the problem with 
> layered architectures where some intermediate layers are 
> general/generic and not application-specific. For example, a 
> generic tree-traversal (intermediate) layer may have to propagate 
> application-defined exceptions from the application-specific 
> "action" routines in a lower layer, to the application's handlers 
> in a higher layer. I don't see how to do that easily with explicit 
> exception contracts. It may be easier in a language with exception 
> classes that can be derived into exception subclasses that have 
> application-defined occurrence-specific data components. The 
> intermediate layer could define its own exception class(es) for 
> such propagated exceptions and the application would define 
> subclass(es) with application-specific information. The contract of 
> the intermediate layer could the list the exception class(es), not 
> the subclass(es).

I think there is no simple answer to this. What could help IMO is:

1. Conditional exception contracts (for things like Storage_Error and
exceptions from the closures)

2. Inheritable exception contracts (to be able to refer to a group of
exceptions from another subprogram)

3. Making exceptions an ordered type with some kind of tree-like distance.

4. Renaming/delegation of exceptions.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de