Making a checked exception a RuntimeException

Question

I'm working on a legacy system that has a custom exception that's used gosh-frickity-everywhere. It was inspired by the ServletException class, that said "well any time you have an exception in your Servlet, you'll want to throw this ServletException ".

As the system evolved (over 10 years) a more robust system of catching the exceptions at a higher level has taken place and it's no longer necessary to wrap every exception in this custom exception. (One could argue it never was, but that's another story. It's a stable app, so I tend not to complain too much!!) But we're not going to be refactoring them all at once, just slowly over time.

However, one thing that would make things simpler going forward would be if the custom exception were a runtime exception instead of a checked exception. This way we wouldn't need to explicitly catch it everywhere, and legacy code that hasn't been refactored yet will just continue to throw this the same way as they'd throw a null pointer exception if one occurred.

My question is... What are the side effects of taking a once checked exception and making it a runtime exception?

I can't think of any, aside from warnings for unnecessary check and throws declarations, but it would be nice to get input from someone who has been down this road before.

Answer 1

Changing a checked exception into an unchecked one has very little practical effect on existing, working code, but you do need to watch out for the possibility that somewhere in your code you catch (RuntimeException ...) . Such catches do not intercept your custom exception now, but they would do if you make it unchecked.

You might also run into issues if you do anything reflective related to methods that throw that exception (which apparently is most of them).

Answer 2

Something like that happened on an old module of a app that I had to maintain. The only problem translating exceptions to runtime is that you may lose granularity but that is entirely up to you to handle.

For example, we had a ton of code like this in the deeper layers:

catch(IOException e){    
    Throwables.propagate(e);
}

We used that pattern carelessly all over that layer and, when we needed to check the exception cause, we always had to get the cause of the exception and that made a lot of boilerplate in higher layers. To this day I believe it's better to create a good class hierarchy of non-checked exceptions in order to preserve granularity. eg

catch(IOException e){
    throw new FileNotCreatedException(e);
}

And with this you can catch the exception easily in other layers and divide errors and fallbacks easily:

catch(FileNotCreatedException e){
   notifyError(e);
} catch(NoMoreStorageException e){
   releaseSomeStorage();
   retryOperation();
}

Answer 3

Here are a few that I can think of

• Runtime exceptions could potentially go to a layer where you didnot intend it to go.
  • ex: a Servlet ---> Service ---> DAO. Runtime exceptions thrown by DAO related to database interactions could potentially land up on Servlet. Clear segregation of layers where each layer handles all exceptions (checked/runtime) at its entry points can ensure that this doesn't happen.
• Runtime exceptions can leave system in an inconsistent state.
  • ex: If the sequence diagram looks like Class A --> Class B ---> Class C and if Class B1 is injected between B and C therefore Class A ---> Class B ---> Class B1 ---> Class C then neither Class A, B, B1 would know that they might have to cleanup when this runtime exception occurs in Class C. In fact this can potentially affect the semantics of any dependency injection.

As a general thumb rule in my opinion:

• Use checked exceptions when you "expect" the exception as part of a normal control flow and know how to handle it. ex: Validation of a business rule say account balance has to be greater than debit amount by atleast 100.
• Use unchecked exceptions when you "don't expect" the exception as part of a normal control flow hence have no means of handling it yet you know that "some class" within your "layer" would handle it to ensure graceful degradation ex: DB connection lost would have handled by your "service" layer entry class.
• Never use error. Only JRE has reasons to throw errors.