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,7d3cb5920e882220 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!eweka.nl!lightspeed.eweka.nl!npeer.de.kpn-eurorings.net!npeer-ng1.kpn.DE!nntp.ilk.net!noris.net!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 11 Dec 2007 09:19:37 +0100 From: Georg Bauhaus User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Exceptions References: <5947aa62-2547-4fbb-bc46-1111b4a0dcc9@x69g2000hsx.googlegroups.com> <475c6ed8$0$13111$9b4e6d93@newsspool2.arcor-online.net> <1kxk3hlfa25dw$.fl2wvbn0tpbg$.dlg@40tude.net> <475d04ea$0$13113$9b4e6d93@newsspool2.arcor-online.net> <194zh0rz03487$.6vxhavjdbpdr.dlg@40tude.net> In-Reply-To: <194zh0rz03487$.6vxhavjdbpdr.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <475e4820$0$17540$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 11 Dec 2007 09:19:44 CET NNTP-Posting-Host: adf153ba.newsspool4.arcor-online.net X-Trace: DXC=2<0IV3Mo55:85[]]\]T0814IUKA:ho7QcPOV3>MfPFKn0N5 Dmitry A. Kazakov wrote: In my view, a language feature is useful if and only if it actually helps reducing the number of bugs. >>> 2. How often does a caller "eat" an exception of the callee instead of >>> propagating it further? My guess is 1 / 10. >> Are you assuming current rules for guessing 10% exception handling, >> i.e., no exceptions are announced by the subprogram declaration? > > I meant that an exception is typically propagated out of 10 scopes before > it gets handled. And? I/O should be counted separately; Using exceptions to signal invalid input to some procedure way up the call stack is indeed not a good idea; in fact, DbC warns you that DbC is not at all about invalid input. >>> There is not that many handlers in a good designed code. >> Hear, hear. [Q] Why do we need more exception announcements, then? > > Because of the damage an unhandled exception does. I don't buy this. Sure, if your program has effects when it continues computing using erroneous values, it may damage things; but this case seems contrued like its counterpart: that in S1; S2;, S1 fails. This failure need not have an effect on S2! >> Will design improve because of subp with exception announcements? > > This is a different question. Clearly any language change has certain > effect on the programming practices and average design. I cannot foresee > how contracts would influence us, programmers. The question, 'How does a language feature affect programs?' is all that matters because programs are produced by writing them in the programming language with a certain set of features. > I can only say that > contracted exceptions are well in Ada spirit. Recently, I've read here on c.l.ada that there is Ada and Ada in the presence of exceptions... >> If programmers do not handle exceptions properly when they >> do not see them in source, will forcing them to handle exceptions >> make them handle exceptions _properly_? > > Exactly so. They still will have an option to keep on ignoring exceptions. > Only if they will announce the program as exception E free, only then, they > will be forced to take care of E. Looks reasonable to me. I suggest you look at some Java code, then. It might change your perspective on programming (not necessarily Java's fault). >> If only the Algol symbol "comment" had been given more emphasis >> in successor languages. A friendly tell-us-what-you-think! >> mechanism is better IMHO than a combination of force together with a >> force absorbing mechanism! (Exception "contracts" together with >> null handlers and the like.) >> >> case Traffic_Light is >> when Red => ... ; >> when Green => .... ; >> when others => >> comment No comment; >> null; -- forces the comment. >> -- Hypothesis: the comment "No comment" will not >> -- pass quality control >> end case; >> >> Remove "others" from the languge? :-) > > The problem here is not others. The problem is the power of a language > construct. Again, the construct gets its effective power from the programmer who uses it. It does not matter that you _can_ "write Fortran in any language"; what _will_ non-theorist programmers actually do? Therefore, a construct should be such that typical use of the construct will help normal programmers writing reasonably good programs. (For me this includes being able to understand and change the program without a PhD in CS.) Here is an example of why I think that treating exceptions like another formal "flow" of control is not going to work in any practical sense. packge Subsys is Oops: exception; -- minor hickup Argh: exception; -- Can't go on An_Error_Has_Occured: exception; type S is tagged null record; -- parent Null_S: constant S; end Subsys; package Subsys.P is type T is new S with null record; function F(X: in out T) return T raise Argh; end Subsys.P; package Subsys.Q is type T is new S with null record; procedure G(X: in out T) return T raise Oops; end Subsys.P; with Subsys; procedure Job raise Subsys.An_Error_Has_Occured; -- client with Subsys.P, Subsys.Q; procedure Job is use Subsys; begin L: declare Result : S'class := Q.G(P.F(Null_S)); -- HERE begin -- ... actions null; end L; exception when Oops => -- Oops is o.K., our software is robust null; when Argh => raise An_Error_Has_Occured; end Subsys.Job; Now the programmers writing Subsys.P and Subsys.Q decide to switch the exceptions raised by F and G respectively. There is a chance that Job won't need a different handler because the set of exceptions to be handled has not changed: {Oops, Argh}. But the meaning of the exceptions has changed significantly, Oops is now the exception that must be handled but it isn't ... I don't see an improvement so far. So we need a different program! One that enables the compiler to notice that the exception announcements have been changed. with Subsys.P, Subsys.Q; procedure Job_Alt is use Subsys; begin -- Split Q.G(P.F(Null_S)); into constituent parts -- so that the compiler can differentiate by exception Handle_G_Exception: declare F_Result : S'class := P.F(Null_S); begin L: declare G_Result : S'class := Q.G(F_Result); begin -- ... actions null; end L; exception when Oops => raise An_Error_Has_Occured; end Handle_G_Exception; exception -- occurence likely raised by P.F when Argh => -- Oops (refactoring missed the name change) -- is o.K., our software is robust null; end Job_Alt; If this style becomes customary for the proper handling of Q.G(P.F(Null_S)); then I'm not sure that announcing exceptions alone is that useful a language change. The example given makes me assume that the increase in SLOC count is opening doors to another row of error candidates. The requires/modifies/ensures model seems more practical to me. It doesn't force handling exceptions; still many programmers using that model seem to be writing preconditions at least.