What the heck? First you say this is not the fallacy of appeal to
authority, and then... you appeal to authority some more.
If you don't mind me riding this horse all the way to the logical
conclusion: If you're looking at Bjarne Stroustrup as a paragon of
language design advice, you're a very strange person.
You don't have to convince me that the idea "Checked exceptions are
sacrosanct, you MUST handle them" is bogus - I've been peddling that
for years. The notion that explicit throws clauses are exhaustive is
obvious bull: Any java programmer that didn't just pick up "java for
dummies" yesterday knows about runtime exceptions and something like
OutOfMemoryError.
On Sep 23, 8:42 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> The term "shadow type system" has been used by such C++ luminaries as Herb
> Sutter, Bjarne Stroustrup and Scott Meyers.
>
> However, this is not the logical fallacy of appealing to authority. It's an
> observation that the very people who shaped the C++ language and added
> exception declarations have themselves declared that it was a bad decision.
> The original designers have disowned the idea as being, ultimately, unfit
> for purpose.
>
> Amongst the problems they observed are:
>
> - declarations give the false impression that they are the only Exceptions
> that might be thrown. I wonder How many programs have crashed because some
> developer has diligently caught all the declared exceptions and therefore
> didn't feel it necessary to write a handler for everything else.
>
> - they give the impression that the compiler will always enforce that
> they're caught. James Iry's `chuck`, Java Puzzlers #43 and Lombok's
> @SneakyThrows all demonstrate how this assumption can fail.
>
> There was only positive thing that came out of C++... The ability to specify
> you'll *never* throw an exception (the no-throw guarantee) has turned out to
> be very useful for reasoning about the correctness/safety of a design.
>
> On 23 September 2010 19:10, Reinier Zwitserloot <reini...@gmail.com> wrote:
>
>
>
> > Why is it awkward? It keeps the API streamlined: You call fileOpen,
> > and you get a FileHandle. When things do not proceed along the
> > "essential path", you get an exception. Which is documented.
>
> > Checked exceptions aren't any less useful just because "some people"
> > decide to call it a "shadow type system" and interpret this to mean
> > "shadow" is somehow "bad".
>
> > On Sep 23, 1:02 pm, Kevin Wright <kev.lee.wri...@gmail.com> wrote:
> > > Surely "having to care about it" is the whole point here!
> > > isn't that the entire justification of *checked* exceptions... that they
> > > force you to "care about it"?
>
> > > Either is an alternative way to insist upon such caring, and it has the
> > > advantages of being composable and not perverting your type signatures.
>
> > > Think about this for a second: what's the signature of our fileOpen
> > > function?
> > > With checked exceptions it's: String => FileHandle (or maybe
> > > FileNotFoundException)
> > > With either it's: String => Either<FileHandle, Error>
>
> > > That bit in the parenthesis is awkward. It's certainly a valid return
> > from
> > > the function, but if you use reflection to examine the return type then
> > > you'll only see `FileHandle`. It's like a wart on the side of the
> > > signature, a return type that isn't a return type - this is why checked
> > > exceptions are sometimes termed a "shadow type system". This kind of
> > > problem will definitely become more apparent once lambda support arrives
> > in
> > > Java.
>
> > > Then again... once lambda support arrives, we can use better solutions
> > based
> > > on the composability of functions.
>
> > > On 23 September 2010 11:11, Reinier Zwitserloot <reini...@gmail.com>
> > wrote:
>
> > > > ... 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
>
> ...
>
> read more »
--
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.
