Your example is too simple. Yes, if what you want is the exact same semantics that you get with exceptions, Either is little better than exceptions. I believe

Your example is too simple. Yes, if what you want is the exact same semantics that you get with exceptions, Either is little better than exceptions. I believe the trick with Either is that it assists one in designing completely different strategies. For example, you can design plugins that accept ambiguous arguments. Sometimes -- often, actually -- you really want to write this: user_photo = load_user_photo(username) ui.display_user_page(username, user_photo) but instead you are compelled to write something like this: try { user_photo = load_user_photo(username) } catch (PhotoFormatException e) { ui.tell_the_user_the_format_is_bad user_photo = NULL } catch (Exception e) { if (ui.interactive?) { ui.tell_the_user_a_terrible_error_occurred(e) } unless (ui.app_in_production?) { throw new MyScopeException(e, "bug") } } if (is_null(user_photo)) { ui.display_user_page_without_photo(username) } else { ui.display_user_page_with_photo(username, user_photo) } (Now, I wrote that in an extra-clumsy way, but only so that we might fully appreciate the clumsiness of the logic. In the real world, I'd probably try to do this more elegantly. The result would probably (a) look cleaner; (b) be far more abstract, confusing, and overdesigned than it needed to be; and (c) contain a half-implemented broken implementation of the Either pattern. ;) What we have here is an application that might need to behave differently if there is a photo or not, and differently if the user is a production customer, a script running in production, or a developer running on a local machine. And because exceptions behave like exceptions whether I like it or not -- they always travel up the stack, they're always in a panic -- that try/catch logic has to be here, at this level. But if load_user_photo() could return an Either I could just pass that Either to ui.display_user_page(). And then I could plug in a "ui" class that does something like this [1]: class Ui { function display_user_page(username, user_photo) { # The customer is blind; user_photo is irrelevant. say("The username is " + username) } } Or this: class Ui { function display_user_page(username, user_photo) { print("The username is " + username) if user_photo.is_good?() { display_photo(user_photo) } } } Or this: class Ui { function display_user_page(username, user_photo) { if user_photo.is_bad?() { throw new HorrorException("I am shocked") } } } or whatever you like. This logic doesn't necessarily belong in your main logic, it belongs in a plugin, and the Either pattern helps you send it there. --- [1] These are oversimplified examples too, of course. In the real world my class would probably do a little more exception handling. There is a certain amount of irreducible pain in dealing with the infinite number of things that might go wrong; all the language can do is give us the flexibility to organize the resulting pile of code as best we can.