... but you keep having to work around an "Either". This seems like a
very bad idea, because now code I write has to care about it. After
all, if I make a method that takes a String, I can't then call this
method if I have an Either[String, Exception].
On Sep 23, 1:44 am, Josh Suereth <joshua.suer...@gmail.com> wrote:
> You've completely neglected the composability of Either, which fail highly,
> IMHO.
>
> Either[A,B] has a really really interesting use case if you can convert it
> into a failure monad. This allows you to chain operations as desired.
>
> // Assume every file operation returns an Either[Exception, T]
> file.open.right.flatMap(doSomethingWithFile)
>
> This will return to us a Either[Exception, T] where T is the result type of
> do something with File. However I can continue to compose functions
> together:
>
> file.open.right.flatMap(doSomethingWithFile).right.flatMap(doSomethingElseW
> ithLastResult)
>
> This will also return a Either[Exception,T] where T is the result type of
> doSomethingElseWithLastResult.
>
> The key here is that if an exception occurs after the first expression, the
> rest of the function is not executed (similarly to exception handling).
> However, I can pass the result of this code somewhere else, *without
> handling the exception* and allow whoever is taking the Either[Exception,T]
> to handle the exception as desired. This means one piece of code can
> create the Either and another that is *not necessarily in the same stack*
> can handle it. I could even pass the Either to another thread.
>
> Of course, this method of capture exceptions should not be used on actually
> critical exceptions, like OOM or such, but it does give you a lot of
> options.
>
> Also, the person who finally handles the exception has something which looks
> like pattern matching.
>
> theResult match {
> case Right(value) => "Success!"
> case Left( t : FileNotFoundException) => "O NOES!!!"
> case Left( t : IOException) => "Something random happened in I/O, good
> luck debugging it"
>
> }
>
> I think it's fair to say that this is more expressive than Java exceptions,
> however they should *not* be used with actually critical exceptions. In
> any case, the Lift framework uses this concept to handle parameters and
> parsing to great effect. See Lift's Box
> monad<http://blog.getintheloop.eu/2010/4/16/understanding-lift-s-box-t-monad>for
> a good example of how this is useful.
>
> On Wed, Sep 22, 2010 at 6:20 PM, 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.
--
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.
