I’ve stayed out of much of the recent debate concerning Exception handling, mostly because I realised I didn’t have much of an opinion on the subject and suspected that even if I did the code I wrote probably didn’t match what I thought I should be doing. To be honest I kind of handle exceptions without any real thought, and after reading Gunjan Doshi’s article “Best Practise For Exception Handling(ONJava.com: Best Practices for Exception Handling [Nov. 19, 2003])”:http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html realised that at least as far as he was concerned, I certainly have room for improvement. Looking over my code after reading the article I’ve noticed that I have been correctly catching user-caused exceptions and erroring appropriately – given that 90% of these errors are caught in validation code its not that surprising. With exceptions generated due to programming errors or problems with resources I’ve noticed a couple of areas where the user has not been properly informed that something has gone decidedly wrong – a few of the exceptions are simply being consumed, logged, and ignored.
Concerning the Checked exceptions vs. Unchecked exceptions debate I’ve always been a big fan of checked exceptions. This probably stemmed from my C programming days when many a programming error was caused by forgetting to check the return type of a system call for an error code. Checked exceptions ensure that at compile time the programmer has taken some action to deal with the result. Gunjan is of the opinion that the only point in throwing a checked exception is when the client can actually do something about it, which is an approach I can certainly understand. Again carrying out a brief audit of my code I have found that all too often I am throwing checked exceptions purely to make sure I catch and handle them in my code rather than giving any real thought to if they should be unchecked. All in all, the article is a good read, and whilst it may not end the debate on the subject of proper exception handling it may at least raise some interesting approaches.