Actually what i'm doing in my code base is duplicating already existing java checked exceptions like MalformedURLException.class by keeping the same exception name while inheriting from RuntimeException.class . Sincerly,i did not find a better way.

I found that really bad,because i've now nearly 8 exceptions duplicated just because, in my case, i can't recover from theses types of exceptions and i don't want to throw them from each level until they reach the higher level as it would make code maintainability a nightmare.

Frankly, i think that oracle/sun should have thought about this case of re-usability and make the type of exceptions flexible and chosen at the moment of throwing, something like the following instead of relying upon exception's parent :

throwChecked new MalformedURLException();

IMO RuntimeException.class and Exception.class both should be uncheck exception and it is up to the developer to choose how it'll be thrown.

  • so my question, did i miss something in my case and analysis ?
  • and does exist a better approach without duplicating?

Best regards !


Note also by duplicating theses exceptions, i found myself obligated to cover all the branches of my classes hence cover all the created exceptions too if i want to have a good coverage.

  • Why do you need the checked version of them?
    – max630
    Commented Nov 13, 2018 at 22:00
  • @max630 i don't need the checked version of them,i'm interested in reusing them in a unchecked way, because in my case,when i'ill throw them,i don't want to force my clients to catch them.
    – isqo
    Commented Nov 13, 2018 at 22:03
  • Ah they are not yours. I see now
    – max630
    Commented Nov 14, 2018 at 5:18

1 Answer 1


Checked exceptions are pretty much unique to Java and while they can have some value, it's really difficult to know when an exception should be checked or not at the time you are writing an API. Your idea is interesting but unless you write a new language you'll need to deal with them as they are.

Your motivation to use unchecked exceptions instead of checked in cases where you can't recover is completely valid. I would probably not duplicate the names of the exception classes, however. There's nothing inherently wrong about it but it could be really confusing to other developers especially if they are used to Java. For example your stack traces will look weird if you capture the cause exception because the exception name will be the same (aside from the package.) You will also (I think) have to use the fully qualified class names in a lot of places which can really make the code ugly.

Instead what I tend to do is create a number of RuntimeException classes that have more names like ConfigurationException or UnrecoverableExecutionException or whatever makes sense in the app. These take a cause parameter which accepts the original checked exception so that the full stacktrace is maintained. This also gives you the opportunity to add more error handling code into these exception classes to do things like capture the context around the exception.

  • This is what I would have answered. This use case is why exception chaining is so useful in Java. Just wrap and throw! Commented Nov 14, 2018 at 22:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.