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,2a687662f09731bb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news2.volia.net!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Java exception model. Was: Re: Ada Quality and Style book discussion ("_Type" suffix) Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.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: <1132227241.9036.44.camel@sonnenregen> <437c877e$1_1@glkas0286.greenlnk.net> Date: Sat, 19 Nov 2005 19:58:07 +0100 Message-ID: NNTP-Posting-Date: 19 Nov 2005 19:57:52 MET NNTP-Posting-Host: 9681d590.newsread4.arcor-online.net X-Trace: DXC=Sm6M]^h_P:0LL2:TY8[@n6:ejgIfPPld4jW\KbG]kaM8FYk:AnJB[C=d6k@k3`FIU7[6LHn;2LCV>[ On Sat, 19 Nov 2005 18:06:05 GMT, Peter C. Chapin wrote: > Dmitry A. Kazakov wrote: > >> I can't tell for Java, but let consider Ada adopting a contract model of >> exceptions. Your reasoning above is flawed. If the designer of Outer knows >> that the exception X cannot propagate out of it then it should be: >> >> procedure Outer is >> begin >> if Some_Complicated_Check then >> begin >> Inner; >> exception >> when X => -- This is not a state, it is a bug >> raise Program_Error; >> end if; >> end if; >> end Outer; > > One of the arguments for exceptions is that they simplify error > handling. I'm not sure code above is much of a simplification over > traditional methods. For example, I don't really want to be forced into > the style above for Constraint_Error every time I index into an array. What does Constraint_Error mean in the program context? The same simple question again: is it a legal outcome of indexing and thus of the subroutine that does it? If yes, then you need not to catch it. If it is not, then why do you let it propagate? BTW, Constraint_Error is an exception I would most like to be checked. In Ada it is not always obvious whether Constraint_Error is a possible outcome. > In any case, using the Java model procedure Outer would have to declare > that it might raise Program_Error. No. Because Program_Error above is just a place holder for an exception that cannot be handled, replace it with Abort_This_Rubbish. Or else it should be: procedure Outer is begin if Some_Complicated_Check then begin Inner; exception when X => -- This is a state, I know how to handle it HERE! end if; end if; end Outer; > Do you really want to force > programmers to put such declarations on every subprogram? That would > render those declarations pointless, wouldn't it? > > Actually in Java, some exceptions are unchecked... like the null > reference exception... because it's clear that forcing programmers to > either handle it or declare it as thrown in every method would be > excessive. A program would be littered with "useless" handlers or else > every single method written would have to say that it might throw a null > reference. Java thus has two classes of exceptions: those that are > checked and those that are not. I think it is reasonable. What Java probably lacks is a good way of composition of exception contracts, like "X raises what Y does except that ones mentioned in Z." > How does one decide into which class a > new exception should go? Checked. I cannot imagine any unchecked exception other than generated by the environment (hardware/OS.) > The whole issue seems like a nasty morass to me. I don't think so. What could be alternative? Both in Ada and in C++ managing exceptions becomes a problem in large projects. I think each practitioner can remember a pair of horror stories about exceptions propagating during library elaboration or in destructors. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de