Ah, yep, the 'switch handlers' around concept. It has some merit. It's
not, however, an argument against exceptions, only against java's
syntax for them. In a hypothetical world this could be made legal:
try {
FileInputStream in = new FileInputStream(....);
catch (FileNotFoundException e) {
....
}
....
}
With the implication that any catches inside try blocks apply for the
entire block they've been written in. I'm not saying that's a
particularly great idea, but it can be done.
Pattern matching has its place, but not for this. FileNotFound should
be handled via an exception because it is the exceptional flow
relative to the point of the operation (the point of the operation, is
to open a file. The point is not to check if a file exists, that's a
side effect). Whether this exceptional flow is expectable, and/or
handleable, should be used as a guideline to choose between checked
and unchecked, but either way the API designer is never going to be
right for everyone; what seems like obviously expectable and
handleable here (file not found), is ClassNotFoundError-esque massive
fail when you're for example opening a hardcoded path that is
guaranteed to exist, for example because it's a cache file you just
wrote there earlier in the execution of this program. If someone
yanked the drive out or deleted your data files right in the middle of
you operating, a catastrophic exception that bubbles all the way up is
exactly what's needed, and the code forcing you to deal with it is
bad. Thus, we need a mechanism that lets you BOTH: (A) let you easily
say (or even let this happen automatically): I don't want to handle
the FileNotFoundException case, because I know that's not expectable
and/or handleable for me here, and (B) that when that problem DOES
occur, that it is not swallowed or obscured, but thrown as an
exception that preferably bubbles up far.
In the pattern match scenario, then, a "no match" exception should be
thrown, but there's just as much legit reason to let pattern match
operations fall through if there are no matches. Thus, you are forced
to either invent two pattern match types, or to make 'exception on no
match' the default and force people to make a "default" match that
does nothing in order to get the fallthrough (as far as I know, not
how matching in most languages that have it works - is it going to go
over well?), or force anyone writing any pattern match to not forget
to add a default: which throws a new exception. If there's anything we
learned from java's checked exception experiment, we know that
remembering to program a certain style in the face of (perceived to
be) rare problems is something very few people do, so relying on that
wouldn't be smart.
On Sep 23, 1:11 am, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> It's a fair point... as written, the example using either would get just as
> bad as the example using try/catch once you start adding methods, the
> comparison was unfairly biased.
>
> It's also quite reasonable to object to the names.
> Thankfully they're just a convention, and can be easily improved. We could
> even create a dedicated FileOpenStatus and have a selection of subclasses.
>
> So after fixing everything:
>
> // using either
> fileOpen(fileName) match {
> case FileNotFound => ...
> case IllegalFilename => ...
> case FileOpened(handle) =>
> doSomethingWithFile(handle)
> moreFileOps(handle)
> yetSomethingElse(handle)
> .
> .
> keepGoing(handle)
> .
> .
> promiseThisIsTheLastOne(handle)
> }
> //if there were other subclasses of FileOpenStatus, the compiler would
> warn you at this point
> //other unanticipated problems can still throw an unchecked exception
>
> If anything, I prefer this layout. It makes it far more obvious where the
> flow is likely to diverge.
> I'll also hasten to add that I'd never write a monster method like this, in
> any language. All that file handling behaviour must absolutely be extracted
> into its own method - one that doesn't declare FileNotFoundException.
>
> Of course you can go far deeper with a full implementation of pattern
> matching. However, my intent isn't to bash Java or promote Scala - I simply
> use Scala here as a Java-like language that's suitable for demonstrating
> pattern matches. More significantly, I wish to demonstrate how Java's
> exception handling mechanism might be lifted into a general-purpose
> construct that's usable in situations unrelated to error handling.
>
> In doing this, cases like FileNotFound could be moved back into the return
> type of the function, where they rightly belong; and checked exceptions
> could be removed from the language - thus getting rid of the shadow type
> system that they represent.
>
> What I think important behind all this is not the comparative likelihood of
> a FileOpened vs FileNotFound, but whether or not FileNotFound is a truly
> Exceptional occurrence instead of something to be reasonably expected.
>
> On 22 September 2010 23:20, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
>
>
>
>
> > .... but the either is noise when "file found" and "file not found"
> > are NOT equally likely. There's no way to know as an API designer. The
> > one thing you can tell is that "file found" is pretty much always
> > going to be a reasonable option. No one is going to call fileOpen when
> > they know for sure it'll fail, there wouldn't be any point. Your
> > further comment that the "catch" will start drifting away makes no
> > sense to me. Let's look at the either example again:
>
> > You're *calling a different method* to handle the actual result
> > ("doSomethingWithFile"). If that's how we're going to handle it, we
> > should be fair and let the try/catch example also use that. But, then
> > the 'catch' for the fileOpen failure is NEVER going to drift away too
> > far. If you're _not_ going to be calling a different method, the
> > pattern matching version is going to make the case Right drift away
> > just as far. This is yet another case where you see (and say, as if
> > you're some sort of authority) that some way that java can't do is
> > better, where its actually just personal preference.
>
> > Then there's "Left" and "Right" which are just ugly, and which also
> > suggest there's only 1 type of exception that fileOpen can throw. try/
> > catch does not suffer from any of these problems.
>
> > I don't understand why this thread has drifted into "try/catch itself"
> > is bad. It started with "forcing onto a programmer the need to check
> > certain exceptions based on method signatures is not a good idea"
> > which most seem to agree with. That's entirely different from the idea
> > that try/catch itself is bad.
>
> > On Sep 22, 2:34 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> > > Lets compare...
>
> > > Apologies for using Scala, my intent here is to demonstrate the
> > differences
> > > in the techniques using a language that supports both styles, not
> > > specifically to advocate Scala.
>
> > > val fileName = """c:\autoexec.bat"""
>
> > > // using either
> > > fileOpen(fileName) match {
> > > case Left(handle) => doSomethingWithFile(handle)
> > > case Right(error) => logError(error)
> > > }
>
> > > //using try/catch
> > > try {
> > > val handle = fileOpen(fileName)
> > > doSomethingWithFile(handle)
> > > } catch {
> > > case Exception(e) => logError(e)
> > > }
>
> > > The try/catch example has a couple of extra lines, but that's hardly
> > > significant. More importantly, as the amount of code grows between the
> > try
> > > and the catch, possible points of divergence for control flow become
> > > increasingly unclear. This is high-risk for
> > > causing maintenance difficulties in the future. using Either, on the
> > other
> > > hand, suggests that "file found" and "file not found" are equally valid
> > > non-exceptional outcomes, and places them on a level footing as regards
> > the
> > > flow of control.
>
> > > On 22 September 2010 13:19, Ricky Clarkson <ricky.clark...@gmail.com>
> > wrote:
>
> > > > The point is that it's your choice what to do. Using Either does not
> > mean
> > > > you have to write lots of if statements, though you can if you like.
>
> > > > On Wed, Sep 22, 2010 at 12:22 PM, Miroslav Pokorny <
> > > > miroslav.poko...@gmail.com> wrote:
>
> > > >> How is either any better than letting catching an exception or letting
> > the
> > > >> code continue in the original spot. One gets a split off into a
> > everythings
> > > >> ok here a file, or jump to there and process the problem ? Using
> > Either ends
> > > >> up being "more" code because we get the branch for free with
> > > >> exceptions...And given FileCreation failed is an exception the flow
> > will be
> > > >> most likely at least a bit different. Continuing on and checking later
> > does
> > > >> not seem to make much sense most of the time.
>
> > > >> --
> > > >> You received this message because you are subscribed to the Google
> > Groups
> > > >> "The Java Posse" group.
> > > >> To post to this group, send email to javapo...@googlegroups.com.
> > > >> To unsubscribe from this group, send email to
> > > >> javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups
> > > >> .com>
> > <javaposse%2bunsubscr...@googlegroups .com>
> > > >> .
> > > >> For more options, visit this group at
> > > >>http://groups.google.com/group/javaposse?hl=en.
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "The Java Posse" group.
> > > > To post to this group, send email to javapo...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups
> > > > .com>
> > <javaposse%2bunsubscr...@googlegroups .com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/javaposse?hl=en.
>
> > > --
> > > Kevin Wright
>
> > > mail / gtalk / msn : kev.lee.wri...@gmail.com
> > > 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 javapo...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > javaposse+unsubscr...@googlegroups.com<javaposse%2bunsubscr...@googlegroups
> > .com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
>
> --
> Kevin Wright
>
> mail / gtalk / msn : kev.lee.wri...@gmail.com
> 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 javapo...@googlegroups.com.
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
