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: a07f3367d7,6327f05d4989a68d X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.24.130 with SMTP id u2mr8346562wif.6.1356837414460; Sat, 29 Dec 2012 19:16:54 -0800 (PST) Path: i11ni337243wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.131.MISMATCH!xlned.com!feeder3.xlned.com!news.astraweb.com!border6.a.newsrouter.astraweb.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!newsreader4.netcologne.de!news.netcologne.de!news.mixmin.net!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Press Release - Ada 2012 Language Standard Approved by ISO Date: Thu, 27 Dec 2012 11:05:39 +0100 Organization: cbb software GmbH Message-ID: <18vzcd215zy19.4p37h9105lca$.dlg@40tude.net> References: <7wrdmbre6jw9.qww9l0uzj6mg.dlg@40tude.net> <14oqoq06zhlu2.tcasif3hdyhw.dlg@40tude.net> <1drh1q1ln2dfh$.a9hwlg01fjfy.dlg@40tude.net> <50d6365d$0$6577$9b4e6d93@newsspool3.arcor-online.net> <1pbg79bz92j3t$.sz41zduivjfp.dlg@40tude.net> <4c101d74-c8cb-45a6-82d4-91923bb950b0@googlegroups.com> <87sj6tre9s.fsf@mid.deneb.enyo.de> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: 6/SyjDFvQ5V7ZR2+GYgbDQ.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2012-12-27T11:05:39+01:00 List-Id: On Wed, 26 Dec 2012 17:00:47 -0800 (PST), sbelmont700@gmail.com wrote: > Consider the static case, where a subprogram has to specify a superset of > all the specifications of subprograms it calls. Not really. It specifies a conditional contract: "I rase E and whatever P raises." I presume that P is explicitly stated, e.g. a callback or an object passed. > This will be of limited value, since you almost always end up being > coupled to an API that you don't have control over (gtkAda, Claw, etc), Ada API will certainly enjoy exception contracts. One of the nastiest problems when using GtkAda is exceptions propagating into Gtk. Since GtkAda is almost 100% user-defined Ada callbacks done from C, you *do* want to be able to contract them not to raise anything. > Secondly, the point is moot for OOP since the goal is to use classwide > types. Putting an exception specification on a parent type automatically > restricts all the child types (which may not even be thought of yet, much > less written) to following that same model, which is often not the case. Exception contract must be inherited. It is governed by the LSP. Conditions may be weakened, promises strengthened. Note that this does not mean that the contract remains exactly same. For example, stream write might have the contract "may raise Ada I/O exceptions." An implementation of a blocking stream could exclude End_Error. > Finally, IMHO, exceptions are NOT a property of the interface but of the > implementation (we will likely have to agree to disagree on this). This is evidently wrong because you can write an exception handler and make the program's behavior dependent on whether the exception propagated. > You can take a subprogram that works one certain way (and potentially > raises one set of exceptions), and then rework the guts to work an > entirely different way but produce the same output with the same inputs, > and raises a whole new set of exceptions; That would be another subprogram with another interface. > e.g. if you allocate and free your variables instead of declaring them, > that changes the subprograms interface because now you might raise > STORAGE_ERROR? Both interfaces have Storage_Error in the contract. No difference, also. Regarding Storage_Error. The contract model should support conditional exceptions. This is the case "I raise if you do" and for Storage_Error it is "I don't raise if there is X free storage elements of stack and Y elements of pool Z." The estimations would be very conservative of course if you wanted it more portable. It is thinkable that some other measurement unit could be deployed to make less architecture dependent. Though Storage_Error handling is more interesting for embedded and RT applications, which are natively less portable than others. Most users would probably never contract Storage_Error anyway. For recursive subprograms and other programs where memory consumption is undecidable yet might be known from other sources (e.g. tests), the programmer should be able to instruct the compiler using a pragma, that the implementation satisfies the contract. > I'm of the school of thought that says every subprogram has just one > inherent contract when it comes to exceptions: as long as all the > parameters and pre/post conditions are met, the subprogram will *never > raise anything*. Why not to state that contract, especially for those who belong to other schools? > Or, to put it another way, an exception is an indication that the > contract with the interface has NOT been met. See, there was a contract then. You are in a contradiction. > You don't need to know which ones may or may not be raised, since as long > as you meet the pre-conditions they won't ever happen anyway. Yes. But you cannot put undecidable stuff into a precondition. This is the backdoor through which End_Error and all other exceptions come in and make themselves comfortable, at our expense of course. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de