James Watson
Posts: 2024
Nickname: watson
Registered: Sep, 2005
|
|
Re: What's Your ShouldNeverHappenException?
|
Posted: Jan 19, 2007 5:59 PM
|
|
> > "An Error is a subclass of Throwable that indicates > > serious problems that a reasonable application > should > > not try to catch." > > In my original post, I wan't catching the Error. I was > letting the JVM print it to stderr and exiting. You were > the one who insisted on logging it. That's a reasonable > request, so I listened to you, compromised, and said, > o.k., lets catch it but just to make sure it gets > logged/captured correctly in your environment. No > attempt at recovery.
But what the root issue is that you are creating the Error. If you just wrapped it as an Exception, there would be no question about catching Errors.
The general rule of thumb is that programs should not try to catch Errors. You are throwing an Error. If the programmers calling your code don't catch Error (as most Java developers won't) then the it won't be caught. Did I not explain this already?
> So I listen to your concerns, compromise with you, and, in > between calling me lazy, not-caring about quality, and > arrogant, you throw dogma at me? (BTW, nowhere is that > javadoc does it say this Error is reserved for JVM > issues)
What dogma? Are you saying the documentation is dogma? Does that include any kind of technical documentation?
Not in the JavaDocs but the JLS states:
"Exceptions that are represented by the subclasses of class Error, for example OutOfMemoryError, are thrown due to a failure in or of the virtual machine."
http://java.sun.com/docs/books/jls/third_edition/html/classes.html#41434
But if you just consider documentation like this to be dogma then it's probably not convincing.
> James - just what is your proposal? So far, I've > heard "throw RuntimeException". If that is your literal > design, IMO that's completely wrong, cause > RuntimeException doesn't meet the need, with which you > agree, to say "this is really really unexpected".
I don't think it's important to communication how unexpected it was. Unless I'm going to do something different, what purpose does it serve?
> So I'm guessing you mean to throw a subclass,
Bad guess. I don't see much value in creating an Exception class if it doesn't have any special behavior and I'm not going to do anything different when it's thrown. I can't see why I would need special code for something that is extremely unlikely to occur. It would just fall into the 'something happened that prevents this operation' category. It's not like a DB connection failure where you might want to put up a message saying "try again later". This is one of those 'contact support' kinds of errors.
> These are tedious to catch, and, arguably, a big waste of > time and clutter cause these are only going to be thrown a > handful of times, if that, over the lifetime of the > product.
Even if I did create a sublclass of RuntimeException, I would still just catch Exception at the fault barrier. I'm not sure where you have gotten these ideas. Is that the kind of error handling you work with?
|
|