The cynic in me might interpret that as a condemnation of OOP. As in, AOP is how to get back to functional programming without admitting it. And, I would agree with you! :)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, July 06, 2004 8:57 PM To: [EMAIL PROTECTED] Subject: Re: [Juglist] Structured Exception Handling The problem with such dogma is the question of "system". For instance, suc= h advice does me little good if JBoss is considered "system". As for the API, that=B9s essentially what I was saying. The issue being of course the "continue". Meaning if=20 Public void myMethod() requires exception(Connection c) { doFailableOperation(); //"exception" thrown here doOtherStuff(); } Public void myOtherMethod() { this.myMethod()(this.brokenConnectionHandler(c)); } Public void brokenConnectionHandler(Connection c) { //handle broken connection now what?? Return?? Continue?? } VB had "on error" for code blocks. Like "on error goto errorHandling" and you could call "continue" but where would you be??? It was too ambiguous o= f scope (its been years since I did VB so excuse me for blocking most of the memory out if this isn't 100% accurate). Yes, I work for Jboss. AOP can of course save the world because Chip said so. However, I wonder if this might be a good place for AOP. Meaning attributes and point cuts for *if* you want to handle the exception. And you the developer can bind the exception handling *later*. Of course again= , ambiguity and the potential of *forgetting* could be a problem. However, I wonder if in most cases, the best practice ought not be "fail fast" error handling. Meaning if the file isn't found, throw up and die. If that=B9s no= t good then the user needs to add @handleError myErrorHandler() which will be called instead of "throwUpAndDie()" or something. Anyhow this is fun if not a little academic. -Andy > From: "David Spitz" <[EMAIL PROTECTED]> > Reply-To: "Research Triangle Java User's Group mailing > list."<[EMAIL PROTECTED]> > Date: Tue, 6 Jul 2004 18:57:12 -0400 > To: "'Research Triangle Java User's Group mailing list.'" <[EMAIL PROTECTED] .org> > Subject: RE: [Juglist] Structured Exception Handling >=20 >=20 > Several years ago, I read a paper written by someone in the Navy whose > controversial claim was that programmers should stop writing error handli= ng > code. His point, however, made some sense: mainly, that error handling co= de, > 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 syst= em > deal with it. >=20 > 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. >=20 > Personally, I like the Java approach of providing checked and unchecked > exceptions. There ought to be a mechanism for forcing API users to deal w= ith > "expected exceptions" (for example, broken network connections), while no= t > forcing lazy (or efficient) programmers to deal with problems they can't > normally handle anyway, such as out of memory errors. >=20 > Regards, > David >=20 > -----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 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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? >=20 > Cory >=20 > _______________________________________________ > Juglist mailing list > [EMAIL PROTECTED] > http://trijug.org/mailman/listinfo/juglist_trijug.org >=20 >=20 > _______________________________________________ > 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 _______________________________________________ Juglist mailing list [EMAIL PROTECTED] http://trijug.org/mailman/listinfo/juglist_trijug.org
