From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,ec21c3c7cdc7ff3e
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!news.glorb.com!npeer.de.kpn-eurorings.net!news.n-ix.net!news.belwue.de!th!lucks
From: Stefan Lucks <lucks@th.informatik.uni-mannheim.de>
Newsgroups: comp.lang.ada
Subject: Re: Handling invalid objects
Date: Wed, 22 Mar 2006 19:06:57 +0100
Organization: InterNetNews at News.BelWue.DE (Stuttgart, Germany)
Message-ID: <Pine.LNX.4.58.0603221828120.13316@th.informatik.uni-mannheim.de>
References: <Ni2Uf.9848$wD1.7244@trnddc02>
 <3pKdnRGO2eWjQr3ZnZ2dneKdnZydnZ2d@comcast.com>
 <1peyefbqozdml.afdrxqiuyi0b$.dlg@40tude.net> <dvr53p$4ri$1@sunnews.cern.ch>
 <1c2j4h3onbhmk.p3uisoojg34b$.dlg@40tude.net> <dvruqc$8j$1@sunnews.cern.ch>
NNTP-Posting-Host: th.informatik.uni-mannheim.de
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Trace: news.BelWue.DE 1143050820 18643 134.155.91.85 (22 Mar 2006 18:07:00
 GMT)
X-Complaints-To: news@news.belwue.de
NNTP-Posting-Date: Wed, 22 Mar 2006 18:07:00 +0000 (UTC)
In-Reply-To: <dvruqc$8j$1@sunnews.cern.ch>
Xref: g2news1.google.com comp.lang.ada:3558
Date: 2006-03-22T19:06:57+01:00
List-Id: <comp.lang.ada>

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