> On May 3, 2017, at 3:31 AM, Jaden Geller via swift-evolution
> <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
