The main problem with the Either return type is that it's difficult to deal with a large number of possible exceptions/errors coming from multiple API calls that you wanna deal with in the same or similar fashion. try-catch allows you to group a bunch of calls together, but each Either return type (each API call) has to be tested individually. Every solution is a compromise; there's no free lunch here. Alexey
________________________________ From: Kevin Wright <[email protected]> To: Cédric Beust ♔ <[email protected]> Cc: [email protected]; Casper Bang <[email protected]> Sent: Tue, March 29, 2011 1:09:40 PM Subject: Re: [The Java Posse] Re: How to deal with CheckedExceptions 2011/3/29 Cédric Beust ♔ <[email protected]> > > >2011/3/29 Kevin Wright <[email protected]> > > >> >> >>2011/3/28 Cédric Beust ♔ <[email protected]> >> >> >>> >>> >>>On Mon, Mar 28, 2011 at 1:31 PM, Kevin Wright <[email protected]> >wrote: >>> >>>> >>>>This is the problem causing Java's excessive stack traces, just exemplified >>>>by >>>>Spring more than most other >>>>libraries/frameworks: >>>>http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html >>>> >> >> >>>I like Steve's articles but could you at least be more specific than quoting >>>a >>>ten page blog post? >>> >>> >>>> >>>>The "best technique" to solve this arguably isn't checked exceptions. It's >>>>true >>>>alternate return values coupled with a decent implementation of closures to >>>>pull >>>>much of the boilerplate out of those stack traces. >> >> >>>We have rebutted this claim of yours many, many times. Your proposal is >>>completely missing the non local handling aspect of exceptions. I am baffled >>>why >>>you keep thinking that return values (even alternate ones) are even in the >>>same >>>league as exceptions when it comes to handling errors. > > >>Concrete example time :) >And like I predicted above, your example completely ignores the case where you >want to handle exceptions non locally (e.g. a few stack frames above). Not really... once you have an exception embedded in this form, it's easily set free, having propogated it as far up the stack as you like: def getOrThrow[T](x: Either[Exception, T]): T = x.right getOrElse { throw x.left } And if you want to handle that, you will find yourself having to bubble up your array of Eithers yourself, in effect reinventing exceptions, except in a worse way. > > >In no time, you will find yourself with dozen of methods calling each other >and >each of them returning an array of Either objects. Each code handling such >Either object will have to decide whether they just want to ignore the error >case or handle it. This is not just a nightmare to maintain, it's also a >nightmare to read and to extend. No... The whole point is that they're monads. You can map over Eithers happily ignoring one or another of the possibilities. Nicely summarised here: http://babyloncandle.blogspot.com/2010/03/scalas-alternatives-to-exceptions.html (scroll down to the example with the for-comprehensions) Internally, the methods are easy to write, and type inference will usually allow you to avoid specifying the return type at all. Contrast this with returning objects that are *always* guaranteed to be correct and having errors being bubbled up in a totally separate channel... and therein lies the problem, that separate channel causes absolute havoc if you need to e.g. perform the same operation on members of a collection and handle exceptions from each one independently. You have have multiple channels for the results of processing each item, but are forced to just a single channel to handle errors from all of them. -- >Cédric > > > -- Kevin Wright gtalk / msn : [email protected] mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- 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. -- 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.
