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-Language: ENGLISH,ASCII X-Google-Thread: 103376,98c463a9e98cfdf5 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-14 14:32:15 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!news.tele.dk!small.news.tele.dk!195.54.122.107!newsfeed1.bredband.com!bredband!uio.no!uninett.no!nntp.uib.no!not-for-mail From: Gisle =?iso-8859-1?Q?S=E6lensminde?= Newsgroups: comp.lang.ada Subject: Re: Ada exceptions. unchecked? Date: 14 Jun 2002 21:32:11 GMT Organization: Institutt for Informatikk, UiB Message-ID: References: <8db3d6c8.0206112300.3965a62b@posting.google.com> <3D0750F1.7A12342@raytheon.com> <3D08ABBA.C8AF105@raytheon.com> NNTP-Posting-Host: apal.ii.uib.no Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: toralf.uib.no 1024090331 27108 129.177.16.7 (14 Jun 2002 21:32:11 GMT) X-Complaints-To: abuse@uib.no NNTP-Posting-Date: 14 Jun 2002 21:32:11 GMT User-Agent: slrn/0.9.7.2 (SunOS) Xref: archiver1.google.com comp.lang.ada:25986 Date: 2002-06-14T21:32:11+00:00 List-Id: In article <3D08ABBA.C8AF105@raytheon.com>, Mark Johnson wrote: > Gisle S�lensminde wrote: >> In article <3D0750F1.7A12342@raytheon.com>, Mark Johnson wrote: >> [snip - explanation of java exceptions...] >> > Adding it to Ada at this point would break a lot of code (but also >> > likely FIX a lot of code when implemented). >> > --Mark >> >> Checked exceptions as in Java is in fact a horrible idea. If you assume >> that the program is designed with error handling in mind from the start, >> it could work, but in practice you will discover at some point that some >> lowlevel error condition the highlevel need to handle. In that case >> all the methods in the entire call tree need to be changed. If the >> application is sufficiently large, you simply can't do that. >> > I am not so certain if the problem is... > - the implementation of checked exceptions in Java is broke > - the constraints on implementing code that uses checked exceptions are > too onerous > or something else entirely. > > The point you make addresses a typical application problem. You have a > higher level module attempting to recover from some low level > implementation detail that should be transparent to it. I can argue that > the one of the abstractions used to build the application is broken - > not checked exceptions. Checked exceptions helped you find out that the > design or implementation is broke - fix it. That's only true if you assume that you can make a full design of the whole application in advance. In practice you don't have overview of all aspects of the application area, and most applications is developed in an evolutionary manner One example I know of is a 300.000 SLOC java application where improved memory handling had to be added, since some JVMs never recovers if a new fails due to unsufficient memory. Therefore an exception had to be thrown, so the highlevel could free up memory resources. This was important since the application should run for weeks/months. The problem was that it was not possible to add new signatures to tousands of soubroutines in a reasonable time, and redesign would take even longer time. The soulution was to subclass an existing excepton, and handle the difference in the highlevel layer, which is close to the solution sugested by others in this thread. The solution is in fact an omission of checked exceptions. One of the main problems is that the checked exceptions forces the programer to take an early choice of what to do with the exceptions. Even you handles and design this perfectly yourself, you still have to deal with other peoples code, where you can find code like the following. try{ obj.doSomeThing(); } catch(Exception ex){ //Remember to insert code to handle this properly. } The problem is that exception handling at one layer possibly must be handled in parts of the program where it does not make sense, and that make programmers to do such code "to get the job done". My point is that the strictness of java exceptions is counter-productive. > If THAT was the only problem with checked exceptions in Java, then I > would argue that the addition of checked exceptions to Ada would be a > good idea. However, I am not convinced of that at this time. Java exception is also quite verbose, both in syntax for handling them, and in the fact that each exception is their own class. -- -- Gisle S�lensminde ( gisle@ii.uib.no ) With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. (from RFC 1925)