In stead you are forced to spend 80% of your code handling exceptions. I think the thought ismeaning: when cleaning out stuff, you shouldn't throw out the real valuable parts (even if those were the cause that got you in the mess)
I think you end up with something like:
+ If the thing you are signalling via an Exception could be made
into a error return value that the client code *really should check for* as opposed to *can check for*, then make it a checked Exception. This ensures that the client code will check for it.
+ If what you are returning is guaranteed to be unrecoverable and stop any processing, throw an Error.
+ Else make it a RuntimeException.
The whole point with checked Exceptions was to avoid the case when lazy programmers didn't properly check for ok return codes.
/LS
that if you spend all that time write try{}catch(){}finally{} clauses you also write someting
in that catch(generally a throw unfortunately, and often a more generic one since you don't
waht to throw 3 different exceptions just because you can't (1)Open a file for (2) Reading
because the (3)file can not be found. (Did I forget something?)
BTW, I like exceptions - in general - but Java (especially the standard libs) make so much use
of them that the effect is more like "Oh no - another one" in stead of "Oh yeah - that can happen".
Leon
