2010/9/22 Cédric Beust ♔ <[email protected]> > > The semantic distinction that you're observing is correct, but > distinguishing the two cases doesn't make practical sense.
Why not? Isn't distinguishing cases an essential part of programming at every stage of the process, from requirements gathering through to deployment? > Whether the file is not present at opening time or disappears while you're > using it, you will probably want to handle this error the same way > Absolutely not. In the first case I want to inform the user that the filename they specified can't be opened. In the second case I want to "bail out" gracefully. Unfortunately, FileNotFoundException can ONLY be used as a checked exception, if you're might throw it then you *have* to declare it, regardless of how plausible it is that the error can be recovered from. > so throwing the same exception and catching it a little higher in the stack > frame makes sense to me. > Which is why unchecked exceptions are good. Checked exceptions force you to do something with them NOW, low in the stack frame, either handle them, wrap them, or rethrow them - in which case they must also be rethrown in each intervening method, all the way up to the true handler. > -- > Cédric > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
