An old discussion, but never too old
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 :
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.