If a file doesn't exist to be opened, that's hardly exceptional if a previously valid file vanishes while you're working on it, that's unlikely to be recoverable
FileNotFound after it's already been opened should always be a true, unchecked, exception What you're really saying is that because it *isn't* exceptional for a filename to be valid, then you should be explicit in requiring an API user to check for that condition. But, as the idiom states: "there's more than one way to skin a cat". Other ways that I can think of to deal with the scenario: - fileOpen returns null if the file is not found this is bad, the reason might actually be invalid filename, out of disc space, or some other problem) - fileOpen can return a Null object representing no file this has the same problems as a naked null - fileOpen returns a Status object that contains the result of the attempt, either a failure reason or the file handle better, but doesn't *force* the caller to check the status object before simply retrieving the handle from it - fileOpen returns one of a hierarchy of possible status objects heavy on boilerplate to both read and use, and checks *still* aren't statically enforced - fileOpen returns an Object, it could be a file handle or an Exception, you have to make explicit instanceof checks This is just wrong... - fileOpen returns Either<FileHandle, Exception> best yet, but the language would need pattern matching for this to work, and a static check that any such match is exhaustive - fileOpen can throw one or more checked exceptions bit of a misnomer, as the condition isn't exceptional. However, catch blocks are the closest thing that Java has to built-in pattern matching, so you're slightly subverting the exception mechanism to take advantage of this. I don't see the problem here as relating to recoverability, it's more an issue regarding the lack of pattern matching, and so no really effective way to embed alternate possibilities in the "normal" control flow. It also means that exceptions are being used (and incurring an overhead) in non-exceptional scenarios. 2010/9/22 Cédric Beust ♔ <[email protected]> > > > On Tue, Sep 21, 2010 at 4:03 PM, Kevin Wright <[email protected]>wrote: > >> In what context? >> >> When opening a named file, it should be normal control flow to discover >> the name isn't valid. >> When performing subsequent operations on an already-opened handle, it's >> truly exceptional if the thing has since gone missing, >> > > Exactly, so it's exceptional and recoverable, therefore, it should be a > checked exception. > > Surely, you don't want the user to open a file, manipulate it, then the > file disappears from under them and you never tell them about it... > > -- > 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.
