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

Jon Shier jon at jonshier.com
Sun Aug 14 02:34:01 CDT 2016


	Sorry Charles, I should’ve been more specific. This isn’t about some other type named Error being usable, but about our doubly generic Result and other types being usable with Error as the generic error type. If we have Result defined as:

public enum Result<Value, ErrorType: Error> {
    case success(Value)
    case failure(ErrorType)
}

then attempting to create the type Result<Whatever, Error> results in the error message I posted. For methods that previously returned Result<Whatever, NSError>, where the NSError is either a system error or an Alamofire one, this is something of a problem. Of course, removing the generic error type fixes this but may have an undesirable usability impact, as making Result double generic was the primary reason behind the quick upgrade between Alamofire 2 and 3. I think it’s less of a problem now, as having to enumerate all of the different expected error types is how user’s are supposed to interact with Error in the first place, but at the time it wasn’t desirable to try and force everything through ErrorProtocol for that reason. Perhaps this is a good compromise, where instead of returning all NSErrors from the framework and allowing consumers to add their own to the mix we’ll just create our own AFError type (whether enum or struct) and then anything coming back will have to be checked for that type in addition to the system types. From my testing it looks like users could still wrap everything coming in by capturing the underlying Error.



Jon

> On Aug 14, 2016, at 3:03 AM, Charles Srstka <cocoadev at charlessoft.com> wrote:
> 
>> On Aug 14, 2016, at 1:18 AM, Jon Shier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 	An immediate problem I’m seeing is the error: using 'Error' as a concrete type conforming to protocol 'Error' is not supported, which means we can’t use Error in our Result or Response types, as both the value and error types are generic there. I’m guessing we’ll have to either remove the generic error type, which would greatly impact consumer’s ability to use our APIs with their own custom errors, or wrap all errors in our own error type, which is terrible for a few reasons. Or just keep using NSError I guess. Any clever solutions here?
> 
> Works fine when I try it:
> 
> import Foundation
> 
> struct MyThing {
>     enum Error: Swift.Error, LocalizedError {
>         case doesNotCompute
>         case imSorryDave
>         case mustSterilize
>         
>         var failureReason: String? {
>             switch self {
>             case .doesNotCompute:
>                 return "Does Not Compute! Does Not Compute! Does Not Compute!"
>             case .imSorryDave:
>                 return "I'm sorry Dave, I'm afraid I can't do that."
>             case .mustSterilize:
>                 return "Error! Must Sterilize! Must Steeerrrrilllliiiiiiizzzzzzeeeeeee"
>             }
>         }
>     }
>     
>     func trySomething() throws {
>         throw Error.doesNotCompute
>     }
> }
> 
> let thing = MyThing()
> 
> do {
>     try thing.trySomething()
> } catch {
>     print(error.localizedDescription)
> }
> 
> Outputs:
> 
> The operation couldn’t be completed. Does Not Compute! Does Not Compute! Does Not Compute!
> 
> Charles
> 

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


More information about the swift-evolution mailing list