[swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Charles Srstka]

> On Aug 15, 2016, at 12:12 AM, Jon Shier <jon at jonshier.com> wrote:
> 
>> On Aug 14, 2016, at 9:43 PM, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>> 
>> Is there something wrong with just returning a Swift.Error and using casting to catch specific errors?
> 
> 	Fundamentally, I think there is, as it requires users know every type of error that could possibly be returned by an API to handle them exhaustively, or for users to create some sort of default behavior that may not be optimal or safe in all cases. Unfortunately I understand now that it’s largely unavoidable given the nature of NSError and error handling in Apple’s frameworks in general. So I’ve accepted that’s how we have to do it from now on. My recent questions, however, were merely seeking guidance as a framework developer. I’ve come to the conclusion that there isn’t really a better solution for Alamofire than removing the generic error parameter from the relevant types and letting Error bubble up from the underlying frameworks. Users can still wrap everything in a custom type that captures the underlying errors or handle everything manually. I guess there is no clever solution here.

Why do you need to exhaustively handle every type of error that could occur? Don’t you only need to know about the small subset of errors that you know you can recover from, and for the rest, bail and pass the error on down the chain to whatever ultimately ends up presenting the error?

Charles

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