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-Thread: 103376,7d3cb5920e882220 X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news.glorb.com!newsfeed2.telusplanet.net!newsfeed.telus.net!edtnps89.POSTED!023a3d7c!not-for-mail Sender: blaak@METROID Newsgroups: comp.lang.ada Subject: Re: Exceptions References: <5947aa62-2547-4fbb-bc46-1111b4a0dcc9@x69g2000hsx.googlegroups.com> <475c688f$0$17524$9b4e6d93@newsspool4.arcor-online.net> <4dae26fe-0c8a-46e1-9a33-43c18cf757ae@i3g2000hsf.googlegroups.com> <9f16235c-260a-460b-873c-2183c154cc0c@e25g2000prg.googlegroups.com> From: Ray Blaak Message-ID: Organization: The Transcend User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Dec 2007 00:46:04 GMT NNTP-Posting-Host: 208.66.252.228 X-Trace: edtnps89 1197593164 208.66.252.228 (Thu, 13 Dec 2007 17:46:04 MST) NNTP-Posting-Date: Thu, 13 Dec 2007 17:46:04 MST Xref: g2news1.google.com comp.lang.ada:18934 Date: 2007-12-14T00:46:04+00:00 List-Id: Robert A Duff writes: > The Java programmers who have been mentioned several times in this > thread -- the ones who evilly stick in do-nothing handlers -- are doing > so on purpose. Any attempt to fix that problem via language design will > backfire. Fixing it via education OTOH has a good chance of success. I used to "believe" in checked exception handling, my Ada experience being the likely inspiration. Long experience with Java code leads me to believe they cause more problems then they solve, simply due to the fact that the majority of programmers are coding at a junior or "naive" level. So, when the compiler demands an exception handler, then by golly they provide one -- one that simply swallows the exception with a log of the stack trace. This is in fact far worse than not handling the exception at all, since control flow is not aborted. So, the junior programmer evilly stuck in a do-nothing handler, but they had no clue they were being evil. Note also that the theoretical correctness of whether or not checked exceptions are better is not being disputed here -- the answer is irrelevant. The *practical* effect of checked exceptions, at least with junior programmers, tends, in Java at least, to cause worse results than not handling the exception at all. So, C#'s approach of not having checked exceptions is turning out to be a better design decision in practice, in my experience. Another point is to consider what one usually does with a handled exception. Usually it is to ultimately report it or log it in some manner. Primarily it needs to perculate up to a top level, where some sort of central event loop can be reset. Sometimes some cleanup needs to be done, but that cleanup often tends to be needed for any exception that is thrown, and the exception should often be rethrown anyway so as to continue to abort the control flow. My experience is that most code does not need to handle exceptions at all except at well defined points in the top level. Mind you, with the use of a non-garbage collected language like Ada, one would need to do cleanups with exceptions more often, but that does not imply the need to do specific exception handling. The times I have seen the need for exception specific handling is usually to do with error message generation. Some exceptions need to show stack traces, some need to show different messages, some need to be shown to the user, etc. This kind of thing is easier to centralize in a language where exceptions are first class objects, since one can override exception behaviour (e.g. anything extending from UserException will be shown to the user, anything else will be logged with a stack trace, with only an "unexpected error" shown to the user, paprticular error reasons are shown via overriding the getMessage() method, etc.). I note also that recent APIs for Java (e.g. XML DOM, Joda data/time, D4Bo OODB) tend to use unchecked exceptions in their APIs, since it makes development so much easier for writing and maintaining code against those APIs. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.