James Watson
Posts: 2024
Nickname: watson
Registered: Sep, 2005
|
|
Re: What's Your ShouldNeverHappenException?
|
Posted: Jan 17, 2007 6:45 PM
|
|
> > Yes, but 'should' is the key word. > > IMO, the key word is never. I thought I have been making > that clear, if not, my bad.
But if it's truly 'never' then why bother doing anything at all? The whole point of doing something is so that the app doesn't fold up like a cheap suit when CosmicRayFlippedABitException is thrown. Your approach kind of seems like: if this thing that you don't expect to happen happens, your app will crash very abruptly and inelegantly.
> > I guess the crux of the discussion is this, what > advantage > > do you get from throwing Error as opposed to a > > RuntimeException? > > Why do we have any subclasses of Exception anywhere? So > you can handle "this cant be happening" exceptions > differetly than "the network is down" exceptions. > > Code that catches "mere" RuntimeExceptions is all over.
Code that catches all RuntimeExceptions or specific RuntimeExceptions? I only catch Exception in a few key places and when I do, that part of the app has gone down for the count.
> You can catch the Error.
You can but every authoritative document says you should not. For example, the first sentence of the documentation for the Error class is "An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch."
> I'm not married to using Error, but, IMO, it's a bit > better than RuntimeException.
Why? Can you explain why your expectation that something shouldn't happen means it needs to be handled differently? It really has nothing to do with the severity of the error. If I can't connect to a database, my app is screwed. It's not going to do anything. If something weird happens that I didn't account for because I thought it would never happen, my app is screwed. Why do these need different types of handling?
> > Take Bill Venners example of > > UnsupportedEncodingException. ... > > > For example, someone comes along and > > changes it to another encoding that isn't universally > > supported and doesn't change the catch block. > > If the encoding is configurable, then the exception isn't > a never. But if your code catches the first exception, > then tries to fallback to UTF-8, and I stare at the source > code and see that, and it gets that exception, IMO that is > the "never" case.
But developers are fallible. It may be a never case and a later change makes it possible. If we use an Error, it will crash like a meteorite, if we use a RuntimeException, the user will get a nice error window saying that something didn't quite go right and that they should contact support (if you use loggers effectively, support can already know, actually)
> > If you are paranoid about it, you can always print to > > syserr in a finally block associated with the call to > the > > logger. That might be a good idea, actually. > > o.k., I can agree there. > > re - a bit on loggers - at our company, there is a > religious war between fans of Apache and Java loggers.
That's a hard call. I think Sun blew it with that move. Log4J was already dominant. They should have incorporated it and worked with that team to add any improvements they desired. As far as I can tell, the JDKs logger still doesn't have a lot of the functionality that Log4j provides. The only advantage that I can see is that it comes with the JDK. I considered using it at my new job and after looking at it, I decided against it.
For my open-source project, I'll probably use the JDK version because I don't want to add a dependency to another jar.
> So when I write my code (mainly algorithms), I often have > no idea what logger to call. That's another reason I tend > to avoid loggers and throw exceptions. Let the guys > writing the app can catch them and call their pet logger.
I may have given you the wrong impression here. I don't consider logging to be sufficient error handling at all. If you are writing components to be called from somewhere else, then you are absolutely correct to just throw the exception. All of the points I have been making are assuming a higher-level point in the code. I occasionally exceptions as they are being thrown but that's merely to help with debugging.
Do you use a debugger? I use loggers like dynamic comments. When I'm puzzling over some strange bug, I crank up logging to trace in a few key places and usually it's obvious what's wrong.
> How do you guys handle this?
I would say that you've got a team problem. I would say the best solution is to choose one or the other and make it a standard. It's really not that crucial which one it used and people should get over themselves. I hate drop bracket formatting and we use it at my new job. As much as it pains me to use it (with two-space indention!) I'm going along with it. Consistency is more important than my personal pain.
|
|