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: 103376,3ccb707f4c91a5f2 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Date: 1996/10/17 Message-ID: #1/1 X-Deja-AN: 189962151 references: <325D7F9B.2A8B@gte.net> <326391B6.4B23@gsfc.nasa.gov> <3264CCEB.AC0@gsfc.nasa.gov> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-10-17T00:00:00+00:00 List-Id: In article <3264CCEB.AC0@gsfc.nasa.gov>, Mike Stark wrote: >I agree that this is a subjective judgement. I think that it is a good >feature for designing safe and secure systems. In Ada systems I've >worked on, the exceptions raised were part of the commentary in a >package spec, and that is quite workable. To me, it seems like Java's rules would end up requiring a whole lot of "throws XXX" statements that lie, or bogus exception handlers that can never be invoked. This is because the compile-time rules aren't really very smart about what exceptions can *really* be raised. An example of this shows up in the predefined streams stuff in Java. I forget what they call it, but there's some sort of abstract class or interface that represents streams of bytes, and you can do operations to get the next byte and so forth. There's one subclass that represents *file* streams, and file streams can raise various I/O exceptions. The problem is that this fact percolates up, so that *all* streams claim that they can raise (er, I mean, throw) I/O exceptions, when it's really only streams attached to files that can raise those exceptions. Why should I have to have a handler for I/O errors, when I'm reading from an in-memory stream of bytes, that has nothing whatsoever to do with I/O? And if somebody invents a new sort of stream, that can raise new sorts of exceptions, they have to go back and modify some very general class to say it can throw those exceptions, and modify all the callers to know about it. I agree with the sentiment -- that I would like to know what exceptions are raised by any given call -- but I think Java's rules end up requiring me to "cry wolf" too much. If every routine says "throws most-anything" then it's not much use. Another example (in Ada) is a generic, with a procedure parameter. An instance of the generic can raise whatever exceptions that formal procedure might raise, perhaps. Expressing that precisely requires a much more complicated mechanism than Java provides. Note also that Java doesn't follow its own advice -- the most common exceptions (like dereferencing a null pointer) are exempt from this mechanism. It's always suspicious when the predefined stuff (like dereferencing null pointers, dividing by zero, etc) doesn't obey the same rules that are expected of user code. Ada's solution is not ideal, but Java's isn't either (for different reasons). - Bob