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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6327f05d4989a68d X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.190.193 with SMTP id dj1mr14982881qab.6.1356570047549; Wed, 26 Dec 2012 17:00:47 -0800 (PST) Received: by 10.49.116.34 with SMTP id jt2mr4403398qeb.38.1356570047522; Wed, 26 Dec 2012 17:00:47 -0800 (PST) Path: k2ni3379qap.0!nntp.google.com!ee4no2389885qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 26 Dec 2012 17:00:47 -0800 (PST) In-Reply-To: <87sj6tre9s.fsf@mid.deneb.enyo.de> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=206.53.78.59; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy NNTP-Posting-Host: 206.53.78.59 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Press Release - Ada 2012 Language Standard Approved by ISO From: sbelmont700@gmail.com Injection-Date: Thu, 27 Dec 2012 01:00:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-12-26T17:00:47-08:00 List-Id: This is just one programmer's opinion based on what I've seen in C++ and Ja= va, but exception specifications are a bad path that goes nowhere. Consider the static case, where a subprogram has to specify a superset of a= ll the specifications of subprograms it calls. This will be of limited val= ue, since you almost always end up being coupled to an API that you don't h= ave control over (gtkAda, Claw, etc), which are written pre-2012 and are no= t likely to be updated anytime soon. Unless they are painstakingly revised= to change the default "raises anything" (which is not going to happen, sin= ce you cut out all pre-2012 customers), then all the subprograms that call = them must also 'raise anything', and those that call those must 'raise anyt= hing' as well in a viral nature, and so on and so on for everything, and yo= u end up with all subprograms raising everything, and it's a lost cause. T= he dynamic case (as in C++) is just as bad, since when an unspecified excep= tions happens, the only thing left to do is continue erroneously or obfusca= te things by raising a different exception than what originally happened, a= nd you're actually worse off than before. Secondly, the point is moot for OOP since the goal is to use classwide type= s. Putting an exception specification on a parent type automatically restr= icts all the child types (which may not even be thought of yet, much less w= ritten) to following that same model, which is often not the case. Similar= to the guideance of making the controlling operand 'in out' to anticipate = future child types that might need to make state changes, any parent type w= ould be unwise to dictate what exceptions a future child implementation mig= ht need to raise by putting anything other than a 'raises anything'. So ev= en if you could put perfect exception specifications on everyting, once you= start dealing with the classwide type, it's all out the window anyway. Finally, IMHO, exceptions are NOT a property of the interface but of the im= plementation (we will likely have to agree to disagree on this). You can t= ake 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 s= et of exceptions; e.g. if you allocate and free your variables instead of d= eclaring them, that changes the subprograms interface because now you might= raise STORAGE_ERROR? That's a side effect of the implementation, not a ch= ange to the interface. Otherwise, you would have to go back and update the= interface nearly every time you change the implementation, which defeats t= he purpose. I'm of the school of thought that says every subprogram has just one inhere= nt contract when it comes to exceptions: as long as all the parameters and = pre/post conditions are met, the subprogram will *never raise anything*. O= r, to put it another way, an exception is an indication that the contract w= ith the interface has NOT been met. 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. If you think you need an exception specification, t= hen IMHO what you really need is another precondition. Just my $0.02 -sb