The subject of this RT is the issue of checked vs. unchecked exceptions and the horrible things the abuse of checked exceptions does to our code base...
Agreed - and I've read some of the stuff you mention, but I have a slightly different point of view: I tend to declare "throws Exception" everywhere (or at least in interface declarations), as using unchecked exceptions only can be very confusing to programmers sometimes. Using the throws clause makes it clear that you expect something to eventually happen.
Let's see how this compares with your proposal:
- use unchecked exceptions *by default* unless there's a good reason otherwise, not just because that's the way it's always been done.
I'd use Exception by default instead, to make it plain that I expect something to happen.
- wrap exceptions thrown by 3rd party packages (e.g. org.xml.sax.SAXException) with Cocoon-specific, unchecked exceptions (basicallly, abstain from throwing checked exceptions belonging to a package different from the method's one, as this creates an unnecessary dependence).
Would be wrapped in a specific *checked* exception then.
- write tests to verify that methods don't throw exceptions for valid inputs and that they throw appropriate exceptions (e.g. InvalidArgumentException) for invalid ones.
Sounds good in an ideal world, but do you think this will happen?
- document with a throws clause any unchecked exception that you explicitly throw in a method, even if it's not required to do so. Document it in the javadoc comment too....
Now that's a problem - the risk of overlooking an exception that you throw is high, whereas by using "throws Exception" you can check quickly by removing the throws clause and letting the compiler complain.
I don't have rock-solid arguments for my point of view, personal taste certainly plays a big role in such discussions. Let's hear what others think...
-Bertrand
