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!news3.google.com!news4.google.com!news.glorb.com!news2.arglkargh.de!news.n-ix.net!news.belwue.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" 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: <1168885771.30643.20.camel@localhost> <1168891576.30643.39.camel@localhost> <5NKdnTv2UZfVZTbYnZ2dnUVZ_vipnZ2d@megapath.net> <38z8yk9z1uxn$.1r6qpevwu2i7c.dlg@40tude.net> Date: Tue, 16 Jan 2007 14:26:44 +0100 Message-ID: <13d6dfmiauvby.1ntqh3qbr07gr$.dlg@40tude.net> NNTP-Posting-Date: 16 Jan 2007 14:26:44 CET NNTP-Posting-Host: e966ef8e.newsspool3.arcor-online.net X-Trace: DXC=0I;iI02^E^0^cW`WBF>WQ7enW;^6ZC`4F0oL On Tue, 16 Jan 2007 11:45:54 +0100, Maciej Sobczak wrote: > Dmitry A. Kazakov wrote: > >> 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'(...); >> ... > > or maybe: > > raise Foo_Error with (A => X; B => Y; C => Z); No, Foo_Error /= "Foo_Error with anything." The whole idea is that the contract requires Foo_Error alone. Nothing else, even if from the Foo_Error'Class, is accepted. If Foo_Error were derived from some Base_Error, you could use an extension aggregate: raise (Base_Error with A => X, B => Y, C => Z); The result were Foo_Error again. > as a natural extension for raise with message. > >> One problem with above is that >> >> procedure Foo raises Some_Error'Class; >> >> should be illegal. > > Why? Because otherwise you could raise a type from the class, of which scope is narrower than one of the handler. So the problem would reappear. OK, there could be other means, like freezing Some_Error'Class after the declaration point of Foo for anybody who can directly or indirectly see Foo. I don't know if that could be a way. As I said, it is a problem to deal with, including the example: when E : Some_Error'Class => when E : Some_Error => We definitely do not want whens to become ordered. Even less, to have contracts which cannot be checked. > You would need to allow it at least in those subprograms that > accept class-wide parameters, otherwise the open-close principle of OO > would not hold (it would not be possible to extend the given hierarchy > without messing with *all* the subprograms that operate on existing > class-wide types). An exception hander and raise can be considered as a "caller" and "callee." The exception propagated is the contract for both. Clearly you cannot have the contract more nested than its parties. Except that you didn't want to introduce upward closures with garbage-collected types and classes of. This is doable, but I doubt it would be much usable for a universal purpose language like Ada! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de