Re: Exceptions

Dmitry A. Kazakov wrote:
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.

I don't like that at all, because in my mind End_Error etc. are associated with Ada IO, not with my application -- their meaning (semantics :-) is not appropriate, and I don't want to be Humpty Dumpty and make them mean what I want them to mean.

Of course, if the function in question actually is reading a file, and fails because the file ends at an unexpected point, then End_Error could be appropriate. But for a function that has no connection with IO I would never "reuse" End_Error just to avoid declaring a specific exception.

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.

But surely one of the main points of a contract is to show what a caller may have to do, to handle the propagated exceptions. To "overload" one exception (such as End_Error) with many different meanings, perhaps requiring different handling, would make the caller's job difficult.

I agree that the number of different exceptions that are usefully propagated from most subprograms is generally small, because the caller does not have enough understanding of the possible exceptional situtations in the callee to be able to handle many different exceptions in specific ways.

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.

I think all subprograms would need contracts (to specify the possibly propagated exceptions), not just the few subprograms that have exception handlers. The contract has to be in the subprogram declaration, while the presence or absence of exception handlers is a property of the body.

Exception contracts could become a considerable part of the source code, especially if they would have to include the "always possible" exceptions like Storage_Error and in the absence of any SPARK-like analysis to exclude impossible exceptions from the contract.

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?

Not really. I use informal exception contracts (in comments describing each and every subprogram), so I have not experienced that kind of mess. But I have mistakenly omitted a necessary handler once or twice, generally when the raise-to-handle distance has been very large (fatal or semi-fatal exception).

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.

That would be ideal, and very much in the Ada spirit. But I can see why it is not an easy addition to Ada.

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....

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.

And perhaps also

5. Exceptions as formal generic parameters.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
.

Relevant Pages

  • Re: GNAT packages in Linux distributions
    ... Eiffel cannot do it either, ... E,g, exception contracts, statements about purity of a function, ... Raising of exceptions is an integral part of DbC specs. ... use the subtype Positive. ...
    (comp.lang.ada)
  • Re: about the new Ada 2012 pre/post conditions
    ... mathematics by means of themselves. ... But contracts are still contracts. ... exceptions of interest. ... upper bound a pair Kbytes upward it would eliminate most of problems. ...
    (comp.lang.ada)
  • Re: about the new Ada 2012 pre/post conditions
    ... How are going to marry exceptions propagating from contracts with ... subprogram that made the call. ...
    (comp.lang.ada)
  • Re: Exceptions
    ... In any case, if you have checked exceptions, then you definitely need ... better to fix the capability of the contracts than to ... Once you have unchecked exceptions, the contract really doesn't tell you ... But pretty-much anything can raise C_E in Ada. ...
    (comp.lang.ada)