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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,f66d11aeda114c52 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,f66d11aeda114c52 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Building blocks (Was: Design By Contract) Date: 1997/09/10 Message-ID: #1/1 X-Deja-AN: 271135316 References: <3415BA96.19B1@pseserv3.fw.hac.com> Organization: The World Public Access UNIX, Brookline, MA Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 1997-09-10T00:00:00+00:00 List-Id: In article <3415BA96.19B1@pseserv3.fw.hac.com>, W. Wesley Groleau x4923 wrote: > >> It would be cool if you could check at compile time that all exceptions >> were being handled by the client, and that only the exceptions advertised >> by a supplier get raised (and only in the specified state). Maybe that's >> the Eiffel model already. > >Well, that's one good thing you can say about Java. Or is it (good)? No, it's not good. It leads to "crying wolf" -- that is, one must state that so-and-so might raise such-and-such exception, even when it's obvious it won't. Consider, for example, the stream classes in Java. A stream that represents a sequence of bytes read from an in-memory array has to falsely state that it might raise various I/O related exceptions, despite the fact that it has nothing whatsoever to do with I/O. The sentiment here is good, but it doesn't work given the paricular rules of Java, IMHO. Perhaps a different set of language rules could achieve the benefits without the "crying wolf" problems. - Bob