Re: contracted exceptions

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

On Sat, 09 Jun 2007 22:04:24 +0100, Simon Wright wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 09 Jun 2007 13:32:59 +0100, Simon Wright wrote:
> 
> I was trying to make the point that some restraints on program
> legality can be made in the language by defining constrained types,
> others you're stuck with hand-coded checks:
> 
>    pragma Assert ({correct calling sequence}, "bad calling sequence");
> 
> or if you prefer
> 
>    if not {correct calling sequence} then
>       raise Use_Error;
>    end if;
> 
> All much of a muchness in terms of trying to make sure that the
> program is correct and is used correctly.

That's OK. My point is that raising Use_Error is a correct behavior of the
program. It is not a bug. Therefore it has to be documented:

   "when the sequence is not this and that, then Use_Error is propagated."
 
Such sequences are legal sequences, like an illegal Ada program is a legal
input for an Ada compiler. Therefore the caller has to have a handler for
Use_Error or else document it, etc. This is why exceptions should be
contracted and not considered as "oops, we didn't think about this."

> Also, this check is about a precondition, if the caller violates the
> precondition she has no right to expect me not to raise unheralded
> exceptions!

Oh my. "If you don't do that, then I ..." (:-))

No, if the precondition was violated by the caller, then how this caller is
supposed to handle the exception it does not know? And why would you rely
on this handling, provided that it is exactly one who first violated the
contract?

If I designed pre-/postcondition/invariant stuff for Ada, then I would
consider implementation of all run-time checks in an independent task with
own stack. A violation would immediately about the monitored task, and the
exception would be propagated in the monitor task.
 
>> The contract would be a lie. Another reason is that you could not
>> handle Baz, because that would change the program behavior with and
>> without assertions checked. IMO run-time assertions is an utterly
>> wrong idea.
> 
> As I said before, I see little difference between assertions &
> predefined language checks in terms of where they should be
> used. Clearly you shouldn't use an assertion where the thing being
> checked is legitimate failure behaviour!
> 
>    pragma Assert (not Vessel_On_Firing_Range);
>    Start_Test_Missile_Firing;

Wasn't it an anti-vessel missile?... (:-))

Yes this is what I meant. The above would be legal, and people would use
it, no matter what guidelines say.

> Of course you can suppress (some) language-defined checks, but then
> you get undefined bahaviour at run time if the error condition
> happens. Is it worse to get unexpected exceptions or to compute with
> out-of-range data?

It is same, without any assumptions about the nature of the error. These
assumptions cannot be reasonably made for unknown in advance errors.

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