This is kind of interesting for collapsing two solutions to the error-signaling problem that are usually seen as alternatives. Or at least, I think of them as alternatives, and they're often presented that way.<p>The classic error-signaling approach is in-band signaling through 'error' return values, but that has the problem of any in-band-signaling solution, clash between the control and data values. Two possible solutions are: 1) in-band signaling with a more complex (data,control) encoding scheme, in this case every function returning (value,error-code); or 2) out-of-band signaling. The simplest example of #2 is C's <i>errno</i> facility, with one global out-of-band error status system; exceptions can be taken as a more sophisticated improvement that implements local context, along with infrastructure to make it easy to specify error-handling policies.<p>But it's interesting to think of exceptions as syntactic sugar on an in-band-signaling solution, rather than out-of-band signaling at all (at least conceptually), with Monads wrapping the code to check/propagate the error signal.
How does this work for constructors? I have the habit of guarding against poor input. If a value is null, I'll throw a null pointer exception or an illegal argument exception. While I recognize that both of these unchecked exceptions, I could just as easily throw a ModelArgumentException that extends from Exception.<p>The reason I throw such exceptions is that I don't want my object to be constructed with invalid state (this is especially true when my object is immutable, but has actions). Since I cannot return an Either, I believe that I must either A) throw an exception or B) allow invalid state. I don't like either solution.
the simple use of "Either" does not instantly qualify something as "monadic"<p>you know what else is monadic? NULL pointers. oh wait, you know what else is monadic? unix pipes. you know what else is monadic? CPP. really old shit.<p>just because the word monad isn't everyday english doesn't make it a cool or even an interesting concept. it's just an awkward abstraction for something everyone already intuitively understands. monads were invented for the sole purpose of giving haskell a programmable model for IO, that's <i>it</i>. it's just a concept that's only useful for haskell programming, everything else <i>already</i> has an intuitive programming model for IO.<p>it's like building up integers to be this crazy complicated concept and then saying Exceptions are integers. awesome, good job, you've just found an equivalence, here's a pat on the back (psst <a href="http://en.wikipedia.org/wiki/Church_encoding" rel="nofollow">http://en.wikipedia.org/wiki/Church_encoding</a>). i guess i should expect these kinds of vacuous observations given all the BufferedManagerFactorySingleton crap code java slaves write.<p>you know what else is monadic? state machines. you know what else is monadic? imperative programming. wait wait wait! you know what else is monadic? JAVA ITSELF <i>head explodes</i>