On 22/09/2010, at 9:42 AM, Kevin Wright <[email protected]> wrote:
> 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. > > Without exceptions how else is the file system supposed to communicate all the different causes of failure? Basically what your describing is what we have today with File.delete and friends where it's a pain to figure out why a delete rename and similar actions fail. Half the time all yiu want is message that a human can read etc. By not throwing an exception you've just made my code larger all so I can call an api to get a message. Every other solution except for an exception is more verbose and requires state and s definitely less functional. In goes the filename, give me a file or complain. How can that possibly be made simpler ? -- 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.
