Re: Exceptions

["Peter C. Chapin" <pchapin@sover.net>]

Dmitry A. Kazakov wrote:

>> if Has_Acceptable_Value(X) then
>>   P1(X);
>> end if;
>>
>> What if Has_Acceptable_Value(X) returns true if X is prime... or a
>> positive power of two? I don't believe you can use Ada subtypes to
>> express conditions like that---or indeed many other possibilities.
> 
> Yes, but it that case very design of P1 is in question. Why the set of
> values where P1 is defined does not constitute some semantically integral
> body (like a subtype)?

Well, my example above is a bit contrived. Let's consider a couple of
more realistic examples:

1. X is a string. Has_Acceptable_Value returns true if X is the name
field of some record in a database. The procedure P1 executes some
string handling algorithm that happens to not be meaningful for empty
strings. Thus P1 raises an exception if given such a string. Yet, due to
database constraints (let's say), any X that causes Has_Acceptable_Value
to return true won't be empty so the exception never arises.

2. X is an abstract type representing an XML document.
Has_Acceptable_Value returns true if X is valid according to its
declared schema. P1 does some XML processing but it assumes the document
given to it is well formed and raises exceptions if that is not the
case. Since valid documents are also well formed, those exceptions won't
occur once Has_Acceptable_Value has signed off on X. Indeed, this is one
 of the main reasons why validating documents before processing them is
desirable: it simplifies later error handling.

If I understand what you are saying, one would need to define a subtype
of strings that contains all strings but the empty string (for #1) or a
subtype of my abstract type that contains all valid XML documents (for
#2). Can those things be expressed using Ada subtypes? I suppose it
could be done using type derivation, but is invoking that machinery
really better than just ignoring the possibility that P1 will raise and
letting any unexpected exceptions propagate in the usual way?

The issue is particularly acute when there is an else clause on the if.

if Is_Valid_XML(X) then
  Process_Document(X);
else
  Log_Bad_Document(X);
end if;

Suppose the above is inside a loop that runs over a collection of
documents. Do we really want to include a handler for
Not_Well_Formed_Exception in this procedure just because the contract on
Process_Document says it might raise such an exception? Do we really
want to claim that we propagate that exception when we clearly don't?

You might say that in a careful program (for example in a high integrity
program) unexpected exceptions should not be treated in such a cavalier
manner. I would agree with that. The question is should the language
attempt to force that degree of care on all programs? It's a balance
between usability and safety. As with all things related to security,
overly aggressive policies can backfire when people feel the need to do
silly things to work around them. I suppose at the end of the day it's
really just a matter of taste... which is what makes debates like this
possible. :-)

Peter