# SE-0235 - Add Result to the Standard Library **URL:** \ **Category:** Proposal Reviews\ **Created:** [November 7, 2018, 10:32pm UTC](https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752 "2018-11-07T22:32:55Z")\ **Posts on this page:** 1\ **Showing post:** 37
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [November 8, 2018, 1:08am UTC](https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752/37 "2018-11-08T01:08:52Z")
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](https://forums.swift.org/t/adding-result-ii-unconstrained-boogaloo/17128/18), `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. --- _[View the full topic](https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752)._