> [...] client code is free to not check for errors. The process will not stop nor even print backtrace if the programmer forgets to check; the process will happily go on with invalid / unsupported / mangled / whatever data. [...]

This statement is simply not true, at least in languages that actually have Either data types (read: Haskell). But I'm not sure how to implement the generic class Either in Java.

> But I'm not sure how to implement the generic class Either in Java.

An abstract class with two concrete private implementations and the relevant factory methods (probably on the abstract class).

The part which is going to break you is handling the type-safe unwrapping of error or value. You could do that with blocks/lambdas if Java had blocks/lambdas which worked (Smalltalk-style), but it does not.

Oh, and I think you can't make the abstract class final since you need to extend it, so others are free to extend it as well, and then you're screwed.

I tried implementing a Maybe type in C# once, it did not end well (in the sense that I could not really enforce type-safety, if I remember well), and I'd expect Java would be even worse.

Please elaborate on how it works? Perhaps I got this very wrong; never used an Either<> class.

Would an attempt to access the value (if an error was indicated instead) cause error condition? Would it be similar in nature to an exception?

> Would an attempt to access the value (if an error was indicated instead) cause error condition? Would it be similar in nature to an exception?

Either is a tagged union (actually a sum type), you have a value OR an error, which are typed (haskell uses Left and Right as the constructors for Either, by convention Left holds an error and Right holds a value, because right is correct).

You can not just "cast" your Either, you have to type-check it with a case (or use monadic operators) to unwrap it, and with the right flag the compiler will ensure you're not missing cases. At compile time.

Either is basically Schrödinger's box (the computation resulted in both a value and an error), and the compiler checks that you're set for handling both a dead and a live cat, or it will not let you open the box.

Thanks for explanations; now it makes sense to me.

Another question: is there built-in support, or an idiom or standard practice for unwinding multiple levels of stack? Is it possible to have handler code is not directly in the function that called, but somewhere lower on the call stack -- and have it reached automatically like an exception does?

Btw., it seems the bolder statement I post to HN, the wronger it turns out to be... oh, boy XD

> Another question: is there built-in support, or an idiom or standard practice for unwinding multiple levels of stack? Is it possible to have handler code is not directly in the function that called, but somewhere lower on the call stack -- and have it reached automatically like an exception does?

Not that I know, but I am very much a haskell novice. You may want to ask for further information in /r/haskell, on reddit.

> Now the proposal -- `Let's have a tuple: Either<error_code, return_value> '

The Either data type is not a tuple.

"In mathematics and computer science, a tuple is an ordered list of elements. [...] The term originated as an abstraction of the sequence: single, double, triple, quadruple, quintuple, sextuple, septuple, octuple, ..., n‑tuple, ..., where the prefixes are taken from the Latin names of the numerals. The unique 0‑tuple is called the null tuple. A 1‑tuple is called a singleton, a 2‑tuple is called a pair and a 3‑tuple is a triple or triplet."

http://en.wikipedia.org/wiki/Tuple

"Either" isn't ordered list of elements. It's result of a choice, a tagged sum of sets.

So Either is not a tuple by any mean.

To elaborate:

> "Either" isn't ordered list of elements.

Although the Either<T,U> type looks like a pair definition, an Either<T,U> return value contains only one element of type T or U.

> without examining how the current situation came to be.

The problem, in a nutshell, with just about everything in the field of Computer Science today. See: George Santayana.

Great pointer, thanks!

I don't have problem with doing a full circle -- actually, that's a good thing once in a while. Cue Apple using BSD and GNU for MacOS X.

I take issue with not considering what reasons got us where we are to-day, and what issues we bring back from the past. State of art (previous research and application work) should be laid out. Pros and cons have to be listed explicitly, or at least referenced. Weighted one against the other. I'd call that ``matter of scientific integrity'', if we were talking about Computer Science ;-)