...Are you *really* suggesting that doing:
public someMethod() throws Exception
everywhere is good programming practice?
Dunno about *everywhere* really, but in interfaces declarations I like it.
Problem is, when writing an interface people try to guess what kind of (checked) exceptions might be thrown, and their guess is usually wrong, which leads to all kinds of ugly tricks.
So for me it's either unchecked exceptions as you suggest, or a sufficiently generic checked exception to keep options open.
"throws Exception" is not that much better than unchecked ones, but at least you don't confuse people who might not be aware of the general use of unchecked exceptions that you suggest.
And they might not be aware of it because Cocon is going to use third-party libraries which *do* use checked exceptions. By not following the usual idiom we'd end up with a mix of two things.
...In the real world, what happens is that your checked exceptions get either swallowed or rethrown as unrelated types of exceptions
Here's a case of the former:
} catch (HttpException e) {
if (getLogger().isDebugEnabled()) {
final String message =
"Unable to get WebDAV children. Server responded " +
e.getReasonCode() + " (" + e.getReason() + ") - "
+ e.getMessage();
getLogger().debug(message);
}...
Won't happen if your method throws Exception, unless I'm missing something?
...And here of the latter:
catch (ParserConfigurationException pce) { throw new SAXException("Couldn't get a DocumentBuilder", pce); }..
Same here, if your method throws Exception you're fine.
...Then you have such gems as methods whose only purpose is to wrap exceptions around other exceptions in order to conform to the "throws" clause on some interface:...
eek ;-) I fully agree about the uglyness in your example.
...Since, *most* of the time, you have no idea what to do with the exception you've caught, you might as well overlook it. At least, you'll save a few lines of code.
With your approach, you end up with code like:
try { x.someMethod(); // throws Exception } catch(Exception ignored) { // TODO: do something with this exception }
That is, if you're lucky enough to have programmers put in a TODO comment in there. And nobody is ever going to remove the "throws" clause...
Ok, point taken: it's easier for callers to overlook checked exceptions than unchecked ones, is that what you mean?
...To sum it up, there is *NO* guarantee that, by using checked exceptions, you get more correct code. On the other hand, it is certain that your code will be more verbose and concerned with doing things that are not its concern, like catching and rethrowing exceptions. This just clutters a method's responsibility with extra, irrelevant instructions...
You have obviously put a lot of thinking into this, and if everybody does as much I wouldn't have a problem.
What worries me is that the (mythical) average Cocoon user might get confused by mixing two programming styles: checked exceptions used when interfacing with third-party code (as nearly all blocks do), and unchecked exceptions in Cocoon-specific code, core, etc.
I think a pragmatic view of checked exceptions might be less confusing.
...I must say that I started this discussion with an open mind, but the more I think about it, the more I am convinced that Bruce Eckel is right: Java doesn't need checked exceptions, they are a failed experiment.
I also respect Bruce Eckel a lot, and he might be right. I'm just wondering about applying this in a radical way here.
-Bertrand
