From an Email conversation this evening:

what do you think about it?

For a while, I was "all flame" about Checked exceptions, but then I
read about their limitations (which are why they aren't included in
C#, more about it there :
http://blogs.msdn.com/csharpfaq/archive/2004/03/12/88421.aspx) and
since I wonder what's the best solution.

i was all behind checked exceptions at first too, until some frameworks i used went nuts on them. that´s where i got interested in the 'other' side: don´t use them at all in order not to dictate your user how to handle exceptional behaviour.
that camp, though never really got me.

to me - like most people about software development - this has 80% to do with common sense and 20% with how your belly feels:

the 80% questions are:
1. can your caller reasonably recover from your exception?
2. do you really WANT to FORCE him to handle this?

good example: FileOutputStream throwing FileNotFoundExceptions

the caller needs to know that, needs to take this possibility into account and CAN reasonably recover from that.

lousy example: FileOutputStream.close() throws IOException.

what the hell am i going to do with that one?

the 20% come in when you realize, that your client´s code must be inevitably cluttered with try/catch statements beyond the acceptable because, for example, any method of your DAO can throw EntityNotFound-exceptions :>

that´d be a showstopper for any acceptence

but if in doubt, i try Checked before unchecked, and see if it really gets THAT messy. -> Safety first

Should I follow Bruce Eckel recommendation : no checked exception,
only runtime ones so they don't get in the way ? Some good old days
return codes ? Checked exception ?

i think checked exceptions do have a serious advantage, especially for 'not-that-incredibly-experienced-programmers' that are forced to think of all possible execution paths, they had missed otherwise.
almost noone cares about the exception in:

void foo(int i) throws IllegalArgumentException

until he finally hits it.