Java Programming: Checked Exceptions Versus Unchecked Exceptions

Java Programming: Checked Exceptions Versus Unchecked Exceptions

I wanted to write something about checked versus unchecked exceptions for a few weeks because such subject popped at work due to different ways of thinking from different people although with the rash and all that I wasn't able to.

You probably know what a checked and an unchecked exceptions are, but I want to make sure of it, so I'll start by explaining each one.

• A checked exception is an exception which you need to explicitly catch, this means your code has to be sorrounded by a try catch block or your method has to throws such exceptions. These are Exception or subclasses of it.
• An unchecked Exception is an exception which you can but don't have to catch, such exceptions are caught by the java virtual machine itself and get there stack trace printed. These exceptions are RuntimeException or subclasses of it.

The main question is when to use each one. Sometimes people tend to disagree in answer.
There are different school regarding this answer, some think unchecked exceptions are Evil(TM) but there are also others who think we should only have unchecked ones.
I have a friend who once told me that all exceptions should be unchecked and you would only catch them when you really need and want to do something about it. Even though I also like the idea, there's a huge risk here, programmers are lazy and because of that most of the time they wouldn't bother to catch exceptions.

In my opinion both make sense, because sometimes you really want to make the programmer aware that something can go wrong. Making him catch an exception and give proper treatment to it can be a way, although if such treatment is just wrapping the exception in a RuntimeException I don't feel very comfortable about it.

But it's true that sometimes checked exceptions are a huge pain and code like

or

starts showing up in too many places. Maybe when this happens you should ask yourself, should I be doing something here? If so, write the catch code block, otherwise think if it's possible to change the exception you were catching into an unchecked one.

I have to admit I'm not very fond of code filled with try catch blocks or throws, seeing a line of code catching five different kinds of exceptions always had a huge wtf factor for me. When this happens one of two things might be happening:

• You aren't doing much on each catch, or doing always the same thing and you can refactor your code into a single catch block, which catch Exception.
• You are doing different things in each catch block. You should look better into this situation, because it might happen that exceptions are being used as a way of programming and that's not good. When I say way of programming I mean throwing exceptions in result of normal behavior, for example use exceptions as different "return" types.

Another thing that I definitely don't like much is the propagation of throws in methods at different depths. If you want to try catch a given exception only 3 stack frames above, all the methods until there will have to throws such exception.

Unchecked Exceptions make the code look cleaner, since there is no need for these try catch blocks nor the declaration of throws. And you can still catch them if you want to.

Maybe if you have an educated development team you could just use unchecked exceptions, catching them only when really needed. Though, once again, the risk of not catching it somewhere it actually needed to be caught can be high, although you always software testing.

I'm not preaching an unchecked exceptions use only, although I must say that using them has its advantages (and disadvantages) as you could see. But sometimes it might be better just to ensure that everyone is catching that nasty exception that informs that resource X failed.

Putting some thought on using unchecked or checked is always good and in dough discuss with your co-workers, different points of view definitely will show up but in the end everything will help you out on choosing a good option. Remember there are no solutions only commitments, which means, there is no perfect solution meditate on the trade-off of each option.