Vivek Agarwal’s Portal/Java Blog

An IBM Gold Consultant’s weblog about IBM, Lotus, WebSphere, J2EE, IT Processes, and other IT technologies

A controversial topic – exception handling approach …

Posted by Vivek Agarwal on April 27, 2010

Recently a client asked me to put together a short write-up on my preferred Java exception handling approach, and I figured I could blog about it as it has been a WHILE since I wrote anything on my blog! Now exception handling is one of those controversial topics that has the Java world split on checked/unchecked exceptions, and I certainly have an opinion about it. So here come my opinions! 🙂

  • Prefer unchecked versus checked exceptions in general

More often than not, clients are not in a position to handle exceptions, and either end up declaring all checked exceptions in their “throws” clause, or catching them generically and converting them into one “throws Exception” clause, or catching and converting them into a single “throws CustomCheckedException” clause. In none of these scenarios, do checked exceptions lend additional value. Checked exceptions do introduce some “versionability” issues – an earlier version of a method throws exceptions A and B, and now when you add new functionality to this method, it can encounter exception C which it cannot handle either; since checked exceptions are part of the interface, this method should not throw a checked exception C or else it breaks its contract with existing clients. Now you are stuck either converting C into an unchecked exception or modifying all clients – neither of these is a good option. Additionally with checked exceptions you can run into issues with needing to throw many exceptions because you cannot handle them within the method you are writing; once you get to a client that calls 3-4 methods each of which throw 3-4 exceptions each, you now have a client method that potentially needs to throw 12-15 exceptions – not good!

In general, most clients are unable to deal with exceptions, and hence it is preferable to make exceptions unchecked so that you do not require your clients to check for each exception. The client can choose to handle the exceptions that it knows how to handle.
  • If we encounter a checked exception in any code that we write, if we cannot handle the exception, we should in general convert the checked exception(s) from other libraries or base java libraries into an unchecked custom exception. If there is a possibility that a client may be able to do something useful with the exception, use a specific unchecked custom exception; if it is something that the client would not have a chance to do anything with, then make it a generic unchecked custom exception.
  • Anytime we convert an exception, we should nest the underlying exception in the new exception.
  • Never catch an exception and do nothing or do nothing except log the exception occurrence. If the proper way to handle an exception is to ignore it, that’s okay, but it should be clearly commented to ensure that you deliberated over this and consciously chose this option; do include your reasoning in your comment.
  • Never reveal details of your implementation in your exceptions by throwing a checked exception that is specific to a library that you are using. By doing so, you can introduce clients that now have a dependency on a library that you use internally.
  • Never display exception stack traces on a web page; in general favor a generic error message to the user for exceptions that bubble up to the “view”; log a more detailed error at  the server level.
  • Always use a common exception handler to ensure consistency in how exceptions are handled, and allowing us to add common functionality such as notifications/alerts as needed.

I can understand that you may not agree with some or any of this, and I am sure that if you have been around Java for some length of time, it is unlikely that I can sway your opinion! 🙂

3 Responses to “A controversial topic – exception handling approach …”

  1. Vivek Agarwal said

    I forgot to include this in the original post – check out Jim’s blog for some insights on exception handling that are definitely worth a read.

  2. Charles Crouch said

    Cédric Beust has a good recent write up on exceptions here.

  3. Vivek Agarwal said

    Hey Charles! Thanks for the tip; I just went through the Cedric write-up, and I must admit that I am still not swayed from my “Prefer unchecked versus checked exceptions in general” stance. 🙂 Essentially, depending on the context in which method “A” is invoked, an exception thrown by “A” may be recoverable or not recoverable in the caller method. If the caller determines whether an exception is recoverable or not, then as an API provider (my school of thought – anytime you write a method you define an API – in some cases it is a “published API”, and in others a “private API” – yes, I know an oxymoron) I should not force you to handle the exception. I should specify that my API throws X, Y, and Z unchecked exceptions, and leave it up to the caller whether it chooses to catch one or more of the unchecked exceptions. I think one of the comments on Cedric’s post links to a blog entry that I think captures the debate well – check it out –

Sorry, the comment form is closed at this time.

%d bloggers like this: