[tianyicui]

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

[masklinn]

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

[dexen]

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?

[masklinn]

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

[dexen]

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

[masklinn]

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