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]
<[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.
