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.
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).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With