Re: Handling invalid objects

[Stefan Lucks <lucks@th.informatik.uni-mannheim.de>]

On Wed, 22 Mar 2006, Maciej Sobczak wrote:

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

[...]
> 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? :) ).

One thing Ada could reasonably do is to *enable* subroutines to *promise*
to raise no exceptions, or only certain exceptions. (And, of course, to
enable the compiler to verify if this promise is kept. This would, be a
little bit similar to SPARK, which can prove the exception-freedom of
subroutines.)

Of couse, the implication is that the subroutine itself may only use (or
rather "with" ;-) subroutines which make a similar promise, or have to
handle all exceptions ("others").

As an example for a notation, sonsider the following subroutines which any
freedom to raise and propagate exceptions deliberately:

   function "+"(A, B: T) return T;
   procedure Get (Item: out T);
   procedure Put (Item: T);

The remaining source code is not Ada. (Or perhaps it is Ada 2015? :-)

No Exceptions raised:

   function "+"(A, B: T) return T
     raise null;
   procedure Get (Item: out T)
     raise null;
   procedure Put (Item: T)
     raise null;

Some Exceptions may be raised:

   function "+"(A, B: T) return T
     raise Constraint_Error, Program_Error;
        -- can raise or propagate Program_Error, but nothing else

   procedure Get (Item: out T)
     raise Ada.Text_IO.End_Error,
           Ada.Text_IO.Data_Error,
           Ada.Text_IO.Mode_Error,
           Ada.Text_IO.Layout_Error;
        -- can raise or propagate these four exception, none else

   Line_Failed : exception;

   procedure PutLine (Item: T)
     raise Ada.Text_IO.End_Error,
           Ada.Text_IO.Data_Error,
	   Line_Failed;
        -- can raise or propagate these three exceptions none else

   procedure Put (Item: T)
     raise Ada.Text_IO.End_Error,
           Ada.Text_IO.Data_Error,
	   package;
        -- can raise or propagate two exceptions from Ada.Text_IO
        -- and any exception defined in the current package

I could also imagine a package to specify which errors might be raised or
propagated in any of its subroutines. This would simplify notation.
Consider the following almost-complete example for a package specification

with Ada.Text_IO;

package Some_Library
  raise
     Ada.Text_IO.End_Error, Ada.Text_IO.Data_Error,
     Ada.Text_IO.Mode_Error, Ada.Text_IO.Layout_Error,
     Constrained_Error, Program_Error,
     package;

   -- Any subroutine defined here may raise the four exceptons from
   -- Ada.Text_IO, the two exceptions Constrained_Error, Program_Error,
   -- from Standard, and the exception(s) defined in the package, namely
   -- Line_Failed.

   Line_Failed : exception;

   type T is private;

   function "+"(A, B: T) return T;
   procedure PutLine (Item: T);
   procedure Put (Item: T);

private
   type T is ...; -- which type T wold you like?

end Mod_Some;


Further, when a subroutines X formal parameter is access-to-subroutine,
then any exception raised by a subroutine given as an actual parameter
need not be handled by X. This should be the caller's duty.


-- 
Stefan Lucks      Th. Informatik, Univ. Mannheim, 68131 Mannheim, Germany
            e-mail: lucks@th.informatik.uni-mannheim.de
            home: http://th.informatik.uni-mannheim.de/people/lucks/
------  I  love  the  taste  of  Cryptanalysis  in  the  morning!  ------