Errors are bad. Errors don't respect encapsulation. No amount of design work will anticipate a SomebodyPouredACokeOnARouterInDetroit exception. If a system is composable, there's alway the chance that some subsystem is going to throw an error that wasn't anticipated.

Things like Either[A,B] make me cringe because they're just like what we used to do back in the 1980's in C. You know, it used to be that you wanted to write

int doAandB(x,y) { return A(x)+B(y); }

but then you had to deal with error values, and it turns out that A and B never returned a negative integer so you'd write

int doAandB(x,y) { int a,b; a=A(x); if (a==-1) return -1;

    b=B(x);
    if (b==-1)
        return -1;

    return a+b; 

}

3 lines of code balloons to 9 lines of code. Read carefully: adding error handling has tripled the size of this code sample!

That's what exceptions win for you... Effectively you get the extra 6 lines of code written for you. You might argue that the default behavior of exceptions might not be exactly what you want, but it's much better than the first example I wrote... Aborting is a better default behavior than barreling past an error.

Now, Either[A,B] is better than returning an in-band signal like -1, but still requires you to write the bulky error handling code.

A real advantage of having something like Either[A,B] is when you're using asynchronous communications. Just the other day, I was dealing with something that used Scala actors and it turned out that sometimes the "business end" of the actor would fail with an Exception. If you catch the Exception in the actor and send it in a message to the next actor, it lets the next actor see the Exception and decide what it wants to do about the failure.

As for variance of Exceptions, that's a pipe dream. Imagine a system that has a subsystem that looks something up in a 'database'. That 'database' could be an in-RAM lookup table (never throws exceptions), it could be an on-disk lookup table (can throw IOException), it could be a web service (can throw networking-related exceptions), or it could be using something like JDBC (which could throw it's own exceptions).

If you constrain the kind of exceptions that can be thrown by the subsystem, you either destroy the composability of the system or you 'dump-down' the error information that's available to the executive level of the software.

Now, if you REALLY want to move forward but not back with composability of error handling, what's needed is some mechanism that the executive level gets 'hints' that would help it deal with the error. That is, lets it answer questions like:

(i) if I try this again immediately, is it likely that this will succeed? (ii) if I try this again in five minutes, is it likely that this will succeed? (iii) was this error caused by specific bad data I sent, or is this subsystem in a completely failed state... etc.