Le 14 avr. 04, � 14:50, Ugo Cei a �crit :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?
No, what will happen is this:
} catch (Exception e) {
if (getLogger().isDebugEnabled()) {
getLogger().debug(
"My brother went to Cocoonland and all I got was this lousy"
+ " message. If this were a more specific kind of exception,"
+ " I might extract some useful information from it, like HTTP"
+ " or SQL error codes. Too bad!");
}
}which is arguably worse ;-).
Ok, point taken: it's easier for callers to overlook checked exceptions than unchecked ones, is that what you mean?
In practice, yes.
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 suspect in the near future, lots of 3rd party APIs will opt for unchecked exceptions, like JDO, XOM or Spring already do. It's our occasion to do The Right Thing (TM) as we plan for the next version.
Ugo
