Several years ago, I read a paper written by someone in the Navy whose controversial claim was that programmers should stop writing error handling code. His point, however, made some sense: mainly, that error handling code, by its very nature, is rarely tested sufficiently (if at all), and is therefore usually the source of a disproportionate number of errors. That is, if most error-handling code is buggy anyway, why bother? Let the system deal with it.
I don't recall the details of his argument, or the author's name, nor did a cursory web search turn up the paper. Perhaps someone knows the paper to which I'm referring. Personally, I like the Java approach of providing checked and unchecked exceptions. There ought to be a mechanism for forcing API users to deal with "expected exceptions" (for example, broken network connections), while not forcing lazy (or efficient) programmers to deal with problems they can't normally handle anyway, such as out of memory errors. Regards, David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cory Foy Sent: Tuesday, July 06, 2004 2:19 PM To: Research Triangle Java User's Group mailing list. Subject: [Juglist] Structured Exception Handling As I got involved in the .NET world, one of the things that bugged me (among lots of other things) was that classes didn't require you to specify or catch exceptions that it created. So even if I wanted to specify that my account class could throw an "AccountOverdrawn" error, I had no way of decorating the class to make it evident, nor had a way for users of my class to be aware or indeed even note that my class could throw it. In my mind this is a limitation of .NET over Java. Someone then directed me to an interview by Anders Hejlsberg, the chief architect of C# (http://www.artima.com/intv/handcuffs.html). In it both he and Bruce Eckel agree that structured exception handling is not a good methodology, but the reasons they give left me wanting more. The basic comments seem to be that programmers are lazy, and if you want to have a class that inherits from 10 different classes each with 8 structured exceptions they can throw, the lazy programmer is just going to write "catch (Exception e)" and be done with it. They do raise some interesting comments about extensibility and being able to modify base classes though. I've seen some pretty bright minds on this list and am really interested in what you all think about exception handling. Is it a good thing or a bad thing to be able to force using classes to at least acknowledge exceptions? Cory _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
