Exceptions are values in C++, Java, and Python too. They're just values you throw. You can program these values.

As usual, I find that opposition to exceptions is rooted in a misunderstanding of what exceptions really are

Exceptions are values, but normal-value-or-exception (which is what Result<T, E> is) isn’t a value. Review my remarks about map_err, ok_or, &c. with the understanding that Result is handling both branches of the control flow, and you can work with both together, and you might be able to see it a bit more. Try looking at real code bases using these things, with things like heavily method-chained APIs (popular in JS, but exceptions ruin the entire thing, so such APIs in JS tend to just drop errors!). And try to imagine how the collect() forms I described could work, in an exceptions world: it can’t, elegantly; not in the slightest.

Perhaps this also might be clearer: the fuss is not about the errors themselves being values, but about the entire error handling system being just values.

	▲	brewmarche 7 months ago \| parent [-]
		It’s about where the error value ends up versus where the success value ends up. With sum types they both end up in the return value and are handled in the same place. Typically you will now try to let the value flow further with the typical functions (bind/bimap/map/or_else and what else we can come up with). With exceptions they are thrown and end up somewhere else in a catch block, so the path of the success value is now distinct from the path of the error value.