Hi Stephen,
Many candidates seem to go with creating their own subclass of RuntimeException to solve this problem.
Depending on the exception you are catching, wrapping, and rethrowing, this might be logical. There is at least one exception that you probably have to catch even though logically it should
never occur in your application. If it can never happen, then if it does happen, your application state may be invalid, and you are probably safer throwing a subclassed RuntimeException.
The problems with wrapping the exception in one of the exceptions allowed in the method signatures are twofold:
What if the exception you are catching and wrapping does not really fit in the description of the wrapper exception? For example, NoSuchRecordException is just that - it is telling you that the record requested does not exist. Logically, when you get that exception, you would think that the database is still in a valid state, and that you can continue working, just with a different record. You should not expect to get this if your database is in an invalid state and you cannot continue working.What if not all methods which have this problem of an undeclared exception do not all have the AnException that they can throw? For example, many of the methods you have been given could throw an IOException. But (in some provided interfaces) not all of them throw the same checked exceptions. This means that you have the same base exception causing different exceptions depending on the method called. Hmmm, this proably would have been easier to read if I had used the real exception names. Oh well ...
Regards, Andrew