I think it's reasonable to see Result and throw as serving different needs within the general realm of error handling and propagation. As I'd mentioned in the previous thread, throw was intentionally designed with an eye toward loosely-coupled, handled-at-a-distance failures, which is why it features automatic propagation (to minimize the overhead of carrying the error to the handler) and no typing (because types would not really help you handle all uncountably many forms of network/file/hardware/etc. error that could accrete through layers of a system). A lot of the people reaching for Result or wishing for typed throws are dealing with more immediate error conditions for which implicit propagation and try/catch ceremony are overkill, and being able to be more specific about the result type is valuable to contain the set of error conditions. It seems to me like it's valuable to have both, and with some investment in language affordances to make Result as fluent to work with as Optional, it could also take pressure off of throws to do more than it currently does.
4 Likes