« James McLurkin and robot swarms | Main | I've succumbed, I have a Blackberry »

May 25, 2006

Checked exceptions or not?

This has been debated to death and the unchecked guys have the upper hand in most frameworks for now. ObjectGrid uses checked exceptions. A commentor, Ruslan, on my previous ObjectGrid evaluation post mentioned he was on the unchecked side. Checked exception means polluting the code with a bunch of try/catch blocks.

And yep, he's right but you can easily avoid this by throwing those exceptions on the method invoking the OG logic. Now, you have no need for try/catch blocks in the code but the caller of your method still knows what he/she must catch if they invoke your method.

So, this is my logic to why we use checked exceptions. Simply adding the checked exception to the method makes it as pretty as unchecked but you still inform the caller whats expected. So, at the end of the day, I think we can keep both camps happy by using checked exceptions and promoting the pattern of throwing the root checked exception or the actual exceptions on the method with the logic. Best of both worlds, for me yes but as the raging debates over the last year has shown it's a contentious issue. So, this was the logic behind the decision.

May 25, 2006 | Permalink


You're a brave man Billy, you might mention where to put the braces next ;-)

Personally I prefer unchecked exceptions for nearly every case that I have come across. Generally speaking, exceptions are system problems that application code cannot do much about, or programmer mistakes that should be found in testing. I will usually rethrow a checked exception as an unchecked one unless I have a clear case that I can do something about (for instance, doing an LDAP search throws NamingException which may be a NameNotFoundException that means something to the application and I can respond to, or it may be some other system-level exception that I cannot do anything about). The documentation of the exception either as a checked NamingEx or an unchecked equivalent doesn't help the user of the method deal with the actual possible failure conditions as they are obscured by the superclass exception.

Secondly, I believe leaking checked exceptions to be one of the worst possible exception handling techniques. It exposes your implementation details to your client and simply forces the exception handling job to them. Suppose I used ObjectGrid and leaked your checked exceptions through my interface, then I am need to use another cache implementation (say I need to run on another platform), all my clients now need to be changed to either add the new checked exception set, or remove your exceptions and add new generalised exceptions of my own. Whatever I do, I still have to change a lot of code, which I would not have to do if I had used unchecked exceptions (or my own generalised exceptions which would be more work than the unchecked approach).

Lastly, exception handling isn't easy and most programmers I have seen do it poorly as it isn't a first order task for the job at hand - the correct execution path is what they are focused on - and unchecked exceptions don't force them to have to think about exception handling, only the outer calling code needs to deal with them.

So, my try template is simply:

try {
catch (BarException ex) {
throw new RuntimeException(ex);

Begone dastardly checked exception!

Posted by: Jed Wesley-Smith | May 25, 2006 7:55:42 PM

Actually Ruslan have a valid point. It does not make any sense to force user to handle checked exceprion if he has no clue what to do with it. Rethrowing it does not help at all, because it only clutter the code and moves problem to the different place, which would be really bad idea since it spread dependencies. I much more like working with JDBC using Spring framework because it allow me not to worry about unrecoverable errors.

Posted by: eu | May 25, 2006 9:47:46 PM

Braces are my next post :)

Posted by: Billy | May 26, 2006 8:00:29 AM

Java is the only popular language that has checked exceptions, as far as I know. This should be enough evidence that it is not needed in Java either.

Posted by: Me Myself and I | May 26, 2006 8:12:21 AM

Thanks Billy for taking note of the ObjectGrid API issues.

As Jed Wesley-Smith rightfully pointed out declaring ObjectGrid checked exceptions in the "throws" list is not an option.

For example I already have my DAO interface with methods defined:

interface IMyDAO
void persistClient(Client cl);
void removeClient(Client cl);

Then I have bunch of inplementations for IMyDAO (InMemoryMyDAO, JDBCMyDAO, HibernateMyDAO, EJB3MyDAO and so on) and of course application code *only* knows about IMyDAO.

Imagine now I want to add ObjectGrid into the picture and create a new implemetation of ImyDAO: JDBC_Cached_MyDAO

Following your suggestion... I have to change IMyDAO methods and add ObjectGrid exceptions:

interface IMyDAO
void persistClient(Client cl) throws ObjectGridException, UndefinedMapException;
void removeClient(Client cl)throws ObjectGridException, UndefinedMapException;

Sorry, I cannot do it, since it will break my existing DAO consumer code plus I have no idea what to do with my other existing IMyDAO implementations...

In general, I think it is unfortunate that Exception class is checked type. So many developers who starts learning Java also try to use it by default ...
I would have made Uncheked exceptions a mainstream in Java (e.g. Exception hierarchy) and Uncheked as additional hierarchy that is optional to use.

Oh well, even though you admitted that “...the unchecked guys have the upper hand in most frameworks for now.” looks like it is not the case with ObjectGrid. :(

Posted by: Ruslan Zenin | May 26, 2006 4:10:11 PM


Out of curiosity, what's your *personal* opinion in the old checked/unchecked debate? Especially, in the "shared memory" context. So far, I've been strongly in the Aye camp, but I'm strongly interested to know what other people think. And no, it's not the old saw. ;-)

Posted by: diprey | May 28, 2006 4:26:18 PM

I like checked exceptions. I don't like to throw anonymous exceptions in to code further up the call stack where the code likely doesn't know how to handle them at all.

Posted by: Billy | May 29, 2006 6:11:21 PM

Post a comment