[swift-evolution] Replace throws with Result

[Douglas Gregor]

> On May 3, 2017, at 3:31 AM, Jaden Geller via swift-evolution <swift-evolution at swift.org> wrote:
> 
> To be frank, there’s no way this is happening. The rationale for Swift’s error handling is documented <https://github.com/apple/swift/blob/master/docs/ErrorHandling.rst>, and this system was designed and implemented *after* optionals already existed in the language. I don’t think there’s any evidence that this was a horrible decision, especially one that requires a *majorly* source-breaking change to remove.

As a core team member, let me amplify this response a bit: the current error-handling system will not be going away, for the reasons Jaden has stated above.

Maybe we will grow typed throws at some point; maybe Result will get added to the standard library with some nice affordances to map between throwing and Result-producing types; but we’re well beyond the point where we can rip out major features that have been generally well-received.

	- Doug

> – Jaden
> 
>> On May 3, 2017, at 3:06 AM, Jose Manuel Sánchez Peñarroja via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> There is currently a discussion open about throws, but it seems that the idea would be to add optionals to throws. In my opinion it would be much better to just get rid of all the throw error system.
>> 
>> I think an *Result<ErrorT, T>* type would provide much better error handling than the current solution:
>> 
>> - It would work just like Optional. We could use ?, ??, map, all those concepts that are already in use. A Result would basically be like a missing value with an error attached. *mapError* could also be added to transform error types to the appropriate value. 
>> 
>> - We would have a specific error type. Right now throws just returns an *Error*, which is basically a glorified *Any*. Anything can go in there, and it's really hard (or impossible) to know if we are dealing with all the possible options. a Result type would enforce a specific error, so we would gain type safety and we could be sure we are dealing with all the cases.
>> 
>> - It would simplify everything. We could get rid of *try*, *try?*, *throws*, *rethrows*, *do … catch*.
>> 
>> - It could be used asynchronously by just passing the *Result* value. Right now there is a different mechanism for handling async and sync calls. The sync calls have all the *throws*, *rethrows*, must be taken care with *try* and *do … catch*, while in a callback you just send the error.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170503/1200ba24/attachment.html>