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
