> Your Result type seems like a lot of code bloat and casting

Code bloat maybe, although if you really just use it to write code like A.flatMap(B).flatMap(C), then it hardly differs from var a = A(); var b = B(a); var c = C(b) wrapped in a try-catch.

I don't really see a reason for casting, however.

Also my result type is the very minimum. Proper result types should and generally do include a lot more convenience methods (e.g. look at the one that Rust has).

> Every Result returned must be verified, not code I want to develop.

Every error needs to be handled – yes.

But that's also the case with exceptions, just that I don't have a good overview over what exceptions that possibly could be.

In this case I at least know which exceptions could appear.

> As well, you still need all the catches up above unless every function that returns Results also has a try/catch—what a mess.

I'm not entirely sure what you mean by that.

I've mentioned that I'd be against wrapping every exception in a result type, but for specific APIs using Results can still be very useful.

In general, this is much more of a critique of the language design of exceptions than it is a suggestion for programmers to use a language differently than intended by its designers.

> Your problem with exceptions seems to be bad programming and programmers, which in my experience is most. I expect they could make an even bigger mess of Result

My thought is that result types leave you less freedom, which means less options to do something wrong.

Instead of just forgetting to document an exception, check which exceptions could be thrown, not throw new exceptions in an interface that is already in use by other people, now you will have to specifically address the possible exceptions or explicitly ignore them. That leaves less room for human error.

> Exceptions allow for error collection points and most code to be written to run as expected.

Error collection points are made harder using results, that's true, but I disagree that most code should be run as expected.

Generally exceptions should be handled as soon as I know what to do about them. Usually I find that's when I use a certain API (whether internal or from a library). Sometimes that results in "error collection points" when it can throw multiple different exceptions but oftentimes I find myself only catching one or maybe two exception.