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,7d3cb5920e882220 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Exceptions 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: <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> Date: Mon, 10 Dec 2007 11:56:19 +0100 Message-ID: <194zh0rz03487$.6vxhavjdbpdr.dlg@40tude.net> NNTP-Posting-Date: 10 Dec 2007 11:48:36 CET NNTP-Posting-Host: f8629921.newsspool2.arcor-online.net X-Trace: DXC=_>:FnWQSIc6Tia]Ho99G50A9EHlD;3Yc24Fo<]lROoR14nDHegD_]R56YKgLBJdE6?DNcfSJ;bb[5FCTGGVUmh?4LK[5LiR>kg2Lkef==Xnc83 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:18855 Date: 2007-12-10T11:48:36+01:00 List-Id: On Mon, 10 Dec 2007 10:20:38 +0100, Georg Bauhaus wrote: > Do programmers put a block around every procedure call so > that the proper occurence of Constraint_Error is handled? Yes if Constraint_Error shall not propagate further. What is the alternative BTW? To say that it does not propagate, but let it do? Note that to argue against exception contracts on the basis that handling exceptions is difficult is a fallacy. It is like to argue that floating-point type is bad because calculating sine is difficult. > And will this likelyhood increase once subp declarations > announce foreseeable exceptions? > >> 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. >> 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. The goal of software design is to minimize the damage caused by program execution (the best way is not to write any programs at all (:-)). Lesser likelihood of exception propagation is compensated by the damage inflicted by. > 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. I can only say that contracted exceptions are well in Ada spirit. >> This is probably >> the reason why people forget to handle exceptions properly. They are not >> that visible. > > 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 have seen a number of null handlers... > > My guess is that missing else branches or undocumented null "others" > in case distinctions are a related issue. The issue really is > handling cases, not announcing them. Every if implies the possibility > of an else. Still we can have null else branches (or "others" choises). No, only in absence of a contract. Consider: function Foo return ... is begin if ... then return ...; end if; end Foo; This is illegal because of the contract to return a value. I hope you do not propose to make Foo legal because required "else" would spoil so nicely formatted code? (:-)) Exception non-propagation contracts fall under this category. > 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. Others is harmless if it includes only Blue. It can be damaging if it does "all other Integers." Ideally the constructs should be as weak as possible to be able to accomplish the goal. Goto or template solve the problem but they call the devil who won't go back. So "others" does when it refers to a set of big cardinality then covered by null-action. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de