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,86c750b8474bf6d5 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!feeder.news-service.com!newsfeed.freenet.de!npeer.de.kpn-eurorings.net!npeer-ng2.kpn.DE!news.tele.dk!news.tele.dk!small.news.tele.dk!fi.sn.net!newsfeed2.fi.sn.net!news.song.fi!not-for-mail Date: Sun, 08 Jun 2008 20:17:33 +0300 From: Niklas Holsti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20060628 Debian/1.7.8-1sarge7.1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: About String References: <484ABED3.8040909@obry.net> <484b802a$0$23844$4f793bc4@news.tdc.fi> <484bbea5$0$2673$4f793bc4@news.tdc.fi> <1w1h9fk6fsahj$.dd2q4gcgx9re$.dlg@40tude.net> In-Reply-To: <1w1h9fk6fsahj$.dd2q4gcgx9re$.dlg@40tude.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <484c13d6$0$2671$4f793bc4@news.tdc.fi> Organization: TDC Internet Services NNTP-Posting-Host: laku61.adsl.netsonic.fi X-Trace: 1212945366 news.tdc.fi 2671 81.17.205.61:32950 X-Complaints-To: abuse@tdcnet.fi Xref: g2news1.google.com comp.lang.ada:615 Date: 2008-06-08T20:17:33+03:00 List-Id: Dmitry A. Kazakov wrote: > 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: >>> [ About the fact that exceptions raised in a declarative >>> part cannot be handled by the handler in the following >>> handled_sequence_of_statements, and it is an error >>> to try. ] >>> >>>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 agree that exception contracts would work in this example. Ok, exception contracts would reveal some -- perhaps most -- of these errors at compile time, but not all. >>>>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. That is a philosophical reason, and I might even agree with it, but it is not a technical problem. >>>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. Yes. And I like the Ada approach better. > 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. I agree that an exception handler in a package declaration could not do anything to recover or repair the failed elaboration (unless the package declaration is nested in a subprogram, of course, so that the subprogram may be called again with better success). But such an exception handler could still do something useful, for example by logging the problem, invoking some "safing" actions, etc., as long as these actions do not depend on the package that failed its elaboration. > For the second model, it is unclear what will be the status of failed A? The Ada run-time semantics already has a concept of something (eg. a subprogram) that is not "yet" elaborated, and can potentially be invoked before it is elaborated, triggering a run-time elaboration check and possible raising of Program_Error. A package with a failed elaboration could be in a similar state. Note again that I'm not proposing that exception handlers should be allowed in package declarations, just exploring the theoretical possibility. > Say, B with-es A and A has failed. That means that B should also fail. Sure, why not. If A's elaboration fails, all subsystems depending on A should be unusable. I think some distinction between failing package declarations and failing package bodies could be used to contain the spreading of the failure. > -- I still cannot handle A's failure here! I agree that an application could not *recover* from failures in package elaboration. But the application could possibly fail more gracefully, perhaps even continue operating in a degraded mode. > It seems that declarations could not be fixed in the second model. Only in the (unusual) case where a package is nested in a callable entity. If the package elaboration fails on one call, the exception handlers could take some action that makes the next call succeed better. In theory. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .