Monday, December 26, 2011

Howto: Exceptions

At work, we've been helping an intern who needs to learn Java and pass a test in a few weeks. Since we're helping him, I figure I should probably jot down some of what I've learned on my career in case it helps anyone else out.

Now, before I get started, anything I say here should be taken as something to be considered and not gospel. There are those who believe there is only the "one true way" to do things where in reality, there may be several depending on what you're doing, who you're working with/for, etc. Just look at the various coding standards on the internet for doing C coding. Oh, and at least one of them is the "one true coding standard."

I want to start with Exceptions mainly because it's the first thing I thought about writing about. Now, I'm not sure what the "correct" way to handle exceptions is, so I'm going to describe my preferred method of handling exceptions.

First, there's a big difference between errors and exceptions. Exceptions are errors that are unexpected during the normal operation of the software vs. errors which can occur as part of normal operation. For example, if you write a division function, divide by zero is an error because it can happen and should be checked for. However, if you're writing a logger and you run out of disk space, that's not something that we expect to happen, therefore it's an exception.

So, we should not rely on exceptions for any cases that we can resolve programmatically. This means there should never be the case where in the catch block we have logic that affects the results of the program. Instead, if we have any cases where we know that something can happen during the normal operation, these should be checked for without exceptions. Can't recall exactly where I found this originally, but exceptions are expensive operations when they occur when compared to checking for errors. Therefore, if you know an error will occur, it should be checked for whereas exceptions, since they should be very rare, should be caught using exceptions.

Next, I'm a firm believer in capturing exceptions as soon as possible vs. bubbling them up. The big reason for this is that now if an exception occurs, you should get as much information as you need in order to know what caused the exception. On one project, this was not the practice as some others wanted the exceptions to bubble up to a higher level before logging them. This to me is a mistake as you can't capture any of the state where the exception occurs when you just bubble it up to a higher level. However, if you capture the exception as soon as it occurs, you can log any and all necessary information.

Now, if you do have to raise exceptions up to a higher level, then I'd suggest that you first capture the exception at the lowest level, capture as much details as necessary, and then raise a new exception with all of the data stored in it. Remember, the goal is to ensure we have everything we need to figure out what happened so we can resolve it as fast as possible.

On the subject of logging, I highly recommend using some sort of logger to capture exception information. If nothing else, you have a persistent copy of the message.

That last thing I want to bring up is using the generic Exception when capturing exceptions vs. specific exceptions. I prefer to capture generic exceptions since there may be several different exceptions that can be thrown in a try/catch block, but unless there's something different that needs to bone done for a specific type of exception, I don't see the need to capture something specific. Typically, I just capture which exception occurred and perhaps the stack trace. I haven't had the need to do anything else, so it was just simpler to just capture Exception. Also, if for some reason I add a method or one changes and throws a different exception, I don't have to change my catch block.

Now, this is just what I do and it has worked very well for me so far. Now, I'm not saying that it should be done this way, but I wanted to show a way to do it and explain why I do it the way I do. Here's to hoping it helps someone.

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home