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

[Jon Shier]

	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?



Jon
 
> On Aug 14, 2016, at 1:41 AM, Jon Shier <jon at jonshier.com> wrote:
> 
> Doug, et. al.:
> 	Thanks for the discussion so far; I think I understand the new error model from a user’s perspective. However, now I’m looking for some guidance for framework developers. While the proposal laid out the system types would wrap imported Objective-C errors, I don’t see anything for the desired patters for Swift native errors. For instance, in Alamofire we currently either pass through the NSErrors we receive from underlying frameworks or generate our own, usually in our own domain, with unique error codes and such. I can see my way to translating most of these directly to an AFError type that conforms to Error, but some of them require associated values (e.g. the content type validation error needs to know the expected and actual content types). In these cases I’m having a hard time see how these things should be stored, especially when only some cases need this data. Of course, I’m away of the LocalizedError protocol, but that doesn’t seem applicable here, as I’m mostly wondering about storage. Rather than creating types similar to the system error types, perhaps a basic enum based error would work, where only the cases that need it capture values? I’m mostly curious what the anticipated pattern was here.
> 
> 
> 
> Jon
> 
>> On Aug 6, 2016, at 1:15 AM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Aug 5, 2016, at 7:36 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>> 
>>> On Aug 5, 2016, at 8:10 PM, Kevin Ballard <kevin at sb.org <mailto:kevin at sb.org>> wrote:
>>>> 
>>>>> 
>>>>> On Aug 5, 2016, at 5:16 PM, Erica Sadun <erica at ericasadun.com <mailto:erica at ericasadun.com>> wrote:
>>>>> 
>>>>> 
>>>>>> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>> 
>>>>>>> If all you want to do is get the localized description, then you can just say `(error as NSError).localizedDescription`.
>>>>>> 
>>>>>> Just ‘error.localizedDescription’ works now. That was part of SE-0112.
>>>>>> 
>>>>>> 	- Doug
>>>>> 
>>>>> Would it kill to allow:
>>>>> 
>>>>> let err = NSError()
>>>>> err.localizedDescription = "bad things happen"
>>>>> throw err
>>>>> 
>>>>> or even
>>>>> 
>>>>> throw NSError("Bad things happen")
>>>>> 
>>>>> for lightweight use? I ended up refactoring entirely to enum : Error because Swift yelled at me for using NSError(): "this results in an invalid NSError instance. It will raise an exception in a future release. Please call errorWithDomain:code:userInfo: or initWithDomain:code:userInfo:. This message shown only once."
>>>>> 
>>>>> enum Errors: Error {case bad}
>>>>> Errors.bad._code // 0
>>>>> Errors.bad._domain // "Errors"
>>>>> Errors.bad._userInfo // Optional({})
>>>>> Errors.bad.localizedDescription // "The operation couldn’t be completed. (Errors error 0.)"
>>>>> 
>>>>> Bleh.
>>>> 
>>>> NSErrors need a domain/code. It doesn’t make much sense to throw one without it. And besides, there’s a fairly trivial solution for doing what you want to do:
>>>> 
>>>> struct GenericError: LocalizedError {
>>>>     let message: String
>>>>     init(_ message: String) {
>>>>         self.message = message
>>>>     }
>>>>     var errorDescription: String? {
>>>>         return message
>>>>     }
>>>> }
>>>> 
>>>> Now you can just say `throw GenericError(“Bad things happen”)`.
>>>> 
>>>> -Kevin Ballard
>>> 
>>> I know I can build workarounds but if we're going to have the error.localizedDescription, making it an initializable/assignable property just seems like a nice thing™. Why can't we have nice things™?
>> 
>> I don’t actually think it’s a nice thing™ to have it be assignable like you ask, because we should be encouraging people to use typed errors. You may as well just ask for String to conform to Error (in fact, you could just add that conformance yourself and skip the GenericError wrapper entirely).
>> 
>> -Kevin
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

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