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,86c750b8474bf6d5 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!newsfeed.icl.net!newsfeed.fjserv.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: About String 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: <484ABED3.8040909@obry.net> <484b802a$0$23844$4f793bc4@news.tdc.fi> <484bbea5$0$2673$4f793bc4@news.tdc.fi> Date: Sun, 8 Jun 2008 15:16:54 +0200 Message-ID: <1w1h9fk6fsahj$.dd2q4gcgx9re$.dlg@40tude.net> NNTP-Posting-Date: 08 Jun 2008 15:16:55 CEST NNTP-Posting-Host: 90877d27.newsspool3.arcor-online.net X-Trace: DXC=EMgZQdLYRPm016@cHD@m;jMcF=Q^Z^V3h4Fo<]lROoRa8kF On Sun, 08 Jun 2008 14:14:04 +0300, Niklas Holsti wrote: > Dmitry A. Kazakov wrote: >> On Sun, 08 Jun 2008 09:47:30 +0300, Niklas Holsti wrote: >> >>>The solution is just to add one more "begin..end" block, enclosing >>>the "declare .. begin .. end", and handle the exceptions in this >>>outer "begin..end" block. Or handle the exceptions in the >>>subprogram's "begin..end" block and nest the "declare..begin..end" >>>within the subprograms "begin..end". >>> >>>That said, I admit that I, too, have made this mistake once or >>>twice. But not lately. >> >> If exceptions were contracted such, quite nasty, errors could be detected >> at compile time. > > Only if the programmer specifies the exception contracts separately > for the declarative parts and the statements. I don't remember any > such proposals. I had this in mind: function Boo raise Use_Error return String; -- That's not Ada procedure Foo raise null; procedure Foo is X : String := Boo; begin ... exception when Use_Error => -- The handler is misplaced ... end Foo; This won't compile because Use_Error is not handled when propagates out of Boo. But the contract of Foo promises no Use_Error. >>>I wonder if it would be a good idea for Ada to allow an exception >>>handler also in the "declare" part, as follows: >>> >>> -- NOT Ada! >>> declare >>> exception >>> begin >>> exception >>> end; >>> >>>Of course, in this proposal the declaration-exception handler would >>>not have access to the declared variables. >> >> But then, for regularity sake, you would need to add exception handling to >> all declarative parts: > > And why not? Because that would make the margin between declarative and imperative more fuzzy than it already is. >> package A is >> >> exception >> (:-)) >> end A; > > It seems, from your smiley, that you feel that such a structure > would be somehow impossible. I don't see why; the exception handler > could execute any sort of non-erroneous code that could be executed > in any subprogram called as part of the declarations in package A. > For example, it could set some flag in another package to inform > the application that package A cannot be used because its > elaboration failed. If the application uses run-time elaboration > checks, it could even continue executing, as long as it does not > try to use anything in A. I admit that this might need an extended > form of run-time elaboration checks. There are two models of exception handling: 1. Handle and continue 2. Wind-up then handle The first was used by PL/1, I cannot tell if it still has it. The second is Ada's model. It is sufficiently simpler (no upward closures etc) and also more general, because it allows continuation without fixing. Fixing a failed declaration would be the first model. I don't see how this could be made, because the exception handler cannot see failed stuff. Which is because it is still the second model... They don't live together. For the second model, it is unclear what will be the status of failed A? Say, B with-es A and A has failed. That means that B should also fail. But: with A; package B is ... exception -- I still cannot handle A's failure here! end B; So we would need something like exception handlers in with! with A package B ... end B; exception -- OK, I can handle A's failure, but what happened with B? end with A; Nevertheless we still cannot do anything in order to fix B. It seems that declarations could not be fixed in the second model. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de