Ok, so we're getting much more specific that your original "use unchecked exceptions everywhere" proposal (or my understanding of it), aren't we?
Well, I originally wrote: "use unchecked exceptions *by default* unless there's a good reason otherwise". I might be extreme and say that there's never a good reason for checked exceptions, but I'm ready to compromise :-).
Ugo
P.S: I'm reposting here my previous reply to your latest email, because I'm afraid it got lost in local network troubles. Sorry if you see it twice.
Bertrand Delacretaz wrote:
> 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
