I fully agree with Erik's point of view, and I'd like to add some more reasoning to support our recommendation:
without any try/catch.
What is an exception?
- It signals to your caller that your method did not succeed (fulfill its contract) for whatever reason.
- It contains a description of that failure, typically by using a specific exception class, containing a message and saving the stack trace where the exception happened.
- It abruptly aborts the current control flow in the current and all parent method executions, up to a point where you placed a matching try/catch.
This concept of exception has been thoughtfully designed to give you a well-behaving error handling nearly for free.
In your sample code, you want to catch exceptions and re-throw different ones. Why? What do you think your caller will do based on the exception? And how will your translated exceptions make that job easier?
I have to disappoint you: typically your caller isn't interested at all in the reason of the failure. If your caller gets an exception, he'll just abort himself and tell his caller about that fact (typically by just letting the uncaught exception ripple through). So, replacing the exception with a different one is a waste of time in 99% of cases. I've rarely ever seen code where a method took different branches depending on the type of exception it got.
Somewhere up in the call stack, there's a place where some developer decided to put a try/catch, because he thinks he can continue here. But he'll typically not care about the type of exception. Maybe, he'll retry the call, or just show a message to the user and wait for his next action. And all this works with any type of exception, so there's again no reason to translate exceptions.
One thing you should care about is logging. Make sure you log each exception once, and only once. The sysadmins running your software will hate you if you clutter the logfiles with endless repetitions of the same problem, especially if you re-word it at every catch/re-throw level. So, don't log in places where you re-throw the exception. Error logging belongs in places where exceptions are caught for good.
Make sure every exception carries a useful message. Typically all the exceptions coming from mature libraries will typically have a useful message, but there might be cases where you want to add information (e.g. about context like an object ID), and that's a valid reason for a catch/re-throw. Don't log here, but create and throw a new exception containing the extra info and referring to the original exception, if your language supports that (e.g. Java does). So the log eintry has all the original exception information, typically including the stack trace, being the most important debugging aid available in a production setting.
To sum it up with The Golden Rule of Exception Handling:
- You Shouldn't Catch an Exception Here.
- You Really Shouldn't Catch an Exception Here.
- If Despite of The Rule You Catch an Exception Here, Be Sure You Know a Good Reason Why!