But that's because lots of people actually used them and came to the conclusion that they didn't want to manually handle every exceptional case at the call-site. People realized that if an operation has two outcomes, but one of them would cause the entire computation to fail and that outcome happened only 1/1000 of cases, they'd rather just ignore it, and catch any exception up the stack. If many people used Either/Maybe they might come to the same conclusion. So we don't know today if Either/Maybe work well just as we didn't know in 1995 if checked exceptions work well -- simply because the pattern hasn't seen enough use yet (and I have no reason to believe that the conclusion would be any different, namely that a possible though unlikely outcome might want to be handled collectively not near the call-site).
2- Either/Maybe are not for when an outcome "will fail in 1/1000 of cases", so this is an example of how they are unlike exceptions. If what you said was true, it wouldn't make sense for a hybrid language like Scala to have both. Obviously Scala's designers don't consider exceptions and Either/Maybe "identical", do they? (And no, exceptions aren't only used for Java compatibility, though their rampant use is discouraged).
3- You can silence checked exceptions with reckless abandon, but you cannot silence a Maybe just as easily, without resorting to obviously frowned-upon practices; you either handle Maybes by using library functions that already know how to handle them properly, or you handle them manually and you are forced to think about the outcome for each case. You cannot simply say "I don't know how to handle the None case, so I'll leave it blank" (because it won't compile) or "I'll throw an exception" (because that's not how you use Maybe, to the point absolutely no-one uses them like that, unlike the case in Java).
4- I'm sure you know there is plenty of bad stuff about checked exceptions beyond the obvious "lazy/rookie Java programmers swept them under the rug and forgot about them". For example, checked exceptions are terrible for generic code, composable code.
And there are more problems with them which don't happen with Either/Maybe. I truly don't see how you can seriously consider them "identical".
I don't. I used them first over 15 years ago when Haskell was "the next big thing" and I learned it at university. Fact of the matter is that not enough code has been written with them to say that we know how effective they are.
> If what you said was true, it wouldn't make sense for a hybrid language like Scala to have both. Obviously Scala's designers don't consider exceptions and Either/Maybe "identical", do they?
I wouldn't take lessons from Scala. Scala has inheritance types, sum types, structural types and dynamic types, each can be (and is) used in isolation to solve almost all problems. If there's any language with lots of overlapping features, that would be Scala. After all, it's a language designed to study various approaches, not to recommend the "best" ones.
> You can silence checked exceptions with reckless abandon, but you cannot silence a Maybe just as easily, without resorting to obviously frowned-upon practices
You can silence checked exceptions by doing exactly what you'd be doing to handle Maybe: You need to explicitly handle it. The difference is that you can catch multiple exception types in one block.
> For example, checked exceptions are terrible for generic code, composable code.
They're not. They just don't work too well with Java's limited effect system of checked exceptions. As a matter of fact, "checked exceptions" are the basis for effect systems in languages like Koka, and are also the basis of transformations of Haskell-ish monads to type-safe nested continuations, which are more appropriate than monads (yet equally expressive and powerful) for imperative languages.
Moreover, a system of checked exceptions composes much better than monads do. And you don't have to believe me. Phil Wadler says it[1] as does Oleg Kiselyov (who's trying to port the same idea back to monadic notation with free monads). This is my own treatment of the subject (which shows how continuations, of which exceptions are a special case, can do monadic composition without monad transformers, and provide type safety through checked exceptions): http://blog.paralleluniverse.co/2015/08/07/scoped-continuati...
> I truly don't see how you can seriously consider them "identical".
It's not a question of consideration. Wadler and Filinsky proved them to be the same (each from a different direction). See the link to my post above for the exact references.
Still, that's not to say that checked exceptions or Maybe are good approaches. We really don't have data on the subject. It basically comes down to personal preference.
Plenty of code has been written. You don't get to claim "fact of the matter" unless it's actually a fact. In reality you seem to be claiming "I don't have enough practical experience with them" which, while entirely respectable, it's a significantly different claim. How much code is "enough code" anyway, according to your standards?
> I wouldn't take lessons from Scala.
What I'm reading here is: "I don't like your example. I will also pretend to forget other languages which also have Maybe types and exceptions. Also, I'll ignore the part where Maybe/Either are not only used in exceptional 1-in-a-100 situations because it doesn't help my case."
> You can silence checked exceptions by doing exactly what you'd be doing to handle Maybe: You need to explicitly handle it.
How you handle Maybe and how you silence an exception is different in practice and in mindset. Because Maybe is usually used in expression-oriented languages (something which is somewhat at odds with exceptions), you need to provide a value for the None case, and this forces you to think about which value makes sense (and when you can't find one, it's usually a sign your function was poorly designed). Compare this with the all too common:
catch (Exception e) {
log.error("Think about this later, if I remember");
}
Maybes make this approach tremendously uncomfortable, which is a good thing. Unlike in Java, blindly using something like fromJust is strongly frowned-upon.
In any case, you often don't handle Maybes explicitly; it's already handled by rich standard libraries in most languages that advocate the use of Maybe. Compare this to the non-standard chaos that is exception handling ("oops! what will this method do if this other thing throws? will it handle it correctly? I better read the source code"). Which means that in practice both approaches turn out to be quite different.
> They just don't work too well with Java's limited effect system of checked exceptions
"I don't like your example."
> It's not a question of consideration [that exceptions and Maybe/Either are "identical"]. Wadler and Filinsky proved them to be the same (each from a different direction)
Sorry, this is too similar to a Turing Tarpit argument. That two systems can be shown to be formally equivalent is very interesting but means little in practice. After all, code with lots of boilerplate and code with little boilerplate can be shown to be equivalent, but it's not identical in practice.
> Still, that's not to say that checked exceptions or Maybe are good approaches. We really don't have data on the subject
I wish you stopped saying this. Realize that "I don't have experience with this" is not the same as "the world doesn't have experience with this".