On 29 Mar 2011 18:54, "Cédric Beust ♔" <[email protected]> wrote: > > > > 2011/3/29 Kevin Wright <[email protected]> >> >> >>> >>> 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. > > > I understand that, but just because you can apply the operation you need on it without caring whether it's an error not doesn't solve the main problem. You are so obsessed with the façade that monads give you here that you are missing the sheer impracticality of mixing errors in success on the same channel. > > Besides, what you are calling a Monad is more like the null object pattern, which I saw described for the first time in the GoF book, I believe (around 1994). > >
Absolutely, they share some similarities. 'Option' is far closer to the null object pattern though. The real advantage of Either is that it can carry some information about the failure, instead of a simple "these aren't the droids that you're looking for". The basic idea of a monad here is that it's a context within which a closure can operate. So the code "multiply by two" can work within a list, or an Option, or one side of an Either. Monads also compose, so that same code can work within the context of a list of options (for example). Not too dissimilar from the context of "the return value of the method I just called, assuming it didn't throw". It isn't conceptually difficult, just an unfamiliar paradigm for most Java programmers. >> >> >> Nicely summarised here: http://babyloncandle.blogspot.com/2010/03/scalas-alternatives-to-exceptions.html >> (scroll down to the example with the for-comprehensions) > > > Ugh, that's some pretty ugly code there. > It's just different from current practices in Java (the language). The occasional 'right' isn't objectively any uglier than the more familiar mechanics of exception handling. >> >> 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. > > > No, you have one channel where you are guaranteed to be dealing with real objects (no nulls, no partially constructed objects) and one that contains errors. Whether you want the error channel to contain just one error or a collection of all the things that went wrong is an implementation detail, but the important part is that these two channels are completely separated. > How would you apply this single channel to parallel arrays, once they arrive? Presumably a MultipleExceptionException could be implemented, even containing a mapping of input elements to their respective failures, but there's then the problem of what appears in the output array for those elements. Your "no nulls, no partial construction, no inconsistencies" guarantee is in difficulty here. > Anyway, I can't believe I'm arguing for the benefit of exceptions, can we get back to 21st century discussions? This is getting tiresome. > > -- > 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.
