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). 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. Contrast this with returning objects that are *always* guaranteed to be correct and having errors being bubbled up in a totally separate channel... -- Cédric -- 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.
