Le 13 avr. 04, à 21:54, Ugo Cei a écrit :I don't think throws Exception in all declarations is a plus; a function which operates on files could have an IOException, a function which operates on numbers a NumberException
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.
or something akin; in essence, the root of the expected Exception hierarchy (for interfaces and abstratc classes). An illegalArgumentException and NullPointerException
need not be declared (and are not declared) since they form part of the Contract. You can (and should IMHO) declare as many demands as possible *and* convenient
for the user (things that are easily checked) in the contract. If you end up with dozens of exceptions in one function, all possible due to wrong arguments (or combinations
thereof) I think even the interface could use a function_doesNotCheck() throws FewExceptions and function_doesChecks() throws zillions of expetions.
This preference has to do with the way I read interfaces. If I see a throws exception, I just let the code die or do a catch all in the hope it will survive. If I see something
concrete, I know what can happen and I might know a recovery technique.
This of course has the disadvantage that implementing an interface at a later time can be a pain since the newly found exceptions are officially not thrown, and
thus need a hack to propagate (a rewrap or something alike). I think that is very much a matter of taste.
I must admit I have a background in C++, so I perceive exceptions more like errors that as control flow, which probably colours my arguments:(
Leon
