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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,699cc914522aa7c4
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Structured exception information
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <eog0g5$2bn$1@cernne03.cern.ch>
 <wcczm8k8aj5.fsf@shell01.TheWorld.com> <1168885771.30643.20.camel@localhost>
 <th0jaznlzs72$.uirljzpoeskd.dlg@40tude.net>
 <1168891576.30643.39.camel@localhost>
 <5NKdnTv2UZfVZTbYnZ2dnUVZ_vipnZ2d@megapath.net>
Date: Tue, 16 Jan 2007 10:11:34 +0100
Message-ID: <38z8yk9z1uxn$.1r6qpevwu2i7c.dlg@40tude.net>
NNTP-Posting-Date: 16 Jan 2007 10:11:34 CET
NNTP-Posting-Host: 62eb40bb.newsspool3.arcor-online.net
X-Trace: 
 DXC=kCkh69<R^F[f8j24CD<3lPMcF=Q^Z^V3X4Fo<]lROoRQgUcjd<3m<;RDS4;jG_BEXZ[6LHn;2LCV^7enW;^6ZC`TF0oL<hNO29[hUH=e=e<?^^
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:8159
Date: 2007-01-16T10:11:34+01:00
List-Id: <comp.lang.ada>

On Mon, 15 Jan 2007 15:56:14 -0600, Randy Brukardt wrote:

> Yuck. One of the invariants of Ada is that an object of a type can never
> outlive its type. Probably the way to handle this would be the same as
> streaming is handled. After all, the state is should be an extension of some
> predefined type (so that resolution will work properly).
> The effect would be that:
> 
>       raise Constraint_Error with Env'access;
> 
> would raise Program_Error for a failed accessibility check.
> 
> We did look at this issue when working on the Amendment. The "obvious"
> answers seem to have issues with visibility and compatibility with existing
> Ada.Exceptions mechanisms. We sent the proposal back to the author, and
> never got an improved proposal. Thus, it got dropped (no reflection on
> importance; can't do anything without a proposal). In hindsight, it probably
> should have been assigned to someone else, but it wasn't.

I think that a more "obvious" answer to me would be a contracted model of
exceptions a-la Java. Then we would have in Georg's case (the syntax is
imaginary):

   procedure Foo raises Foo_Error; -- Compile error!

   procedure Foo is
      type Foo_Error is exception with ...;
   begin
      ...
      raise Foo_Error'(...);
      ...

The contract of Foo should refer to all exception types it can propagate,
this would automatically exclude any local types.

When Foo would not have any explicit exception contract, then raise
Foo_Error should again give compilation error, because the standard implied
contract would contain only the legacy exceptions of Ada 83.

One problem with above is that 

   procedure Foo raises Some_Error'Class;

should be illegal. Well, this issue should be handled anyway in "when"
clauses, to make them statically checkable:

exception  -- Things like this cannot be legal!!
   when E : Some_Error'Class =>
   when E : Some_Error  =>
   ...

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