[swift-users] Confusing Error localizedDescription output
Jon Shier
jon at jonshier.com
Tue Feb 28 15:36:15 CST 2017
Something strange I just observed. This version of MyError properly prints its localized description (in a Playground).
enum MyError: Error {
case network
case json
case value
var localizedDescription: String {
switch self {
case .network: return "first"
case .json: return "second"
case .value: return "third"
}
}
var errorDescription: String? { return localizedDescription }
}
extension MyError: LocalizedError { }
print((MyError.value as Error).localizedDescription): third
However, this version does not:
enum MyError: Error {
case network
case json
case value
var localizedDescription: String {
switch self {
case .network: return "first"
case .json: return "second"
case .value: return "third"
}
}
var errorDescription: String? { return localizedDescription }
}
extension MyError: LocalizedError { }
print((MyError.value as Error).localizedDescription): The operation couldn’t be completed. (__lldb_expr_103.MyError error 2.)
Surely that’s a bug?
Jon
> On Feb 28, 2017, at 4:32 PM, Jon Shier <jon at jonshier.com> wrote:
>
> Sorry, I forgot that part; MyError does conform to LocalizedError. However, even if it didn’t, Error has a localizedDescription property, so my question was why my implementation of that property wasn’t used in favor of the generated one. Or is that not the case for properties that aren’t required by the protocol? Even with the conformance, treating MyError as Error or LocalizedError doesn’t return the correct value for the property. localizedDescription seems to work fine when talking to Error instances backed by NSError though. This behavior doesn’t seem to be correct, otherwise there’s no way to get a useful description out of a custom Error without also implementing LocalizedError and treating the value as that type instead.
>
>
>
> Jon
>
>
>> On Feb 28, 2017, at 4:10 PM, Jordan Rose <jordan_rose at apple.com <mailto:jordan_rose at apple.com>> wrote:
>>
>> 'localizedDescription' isn't a requirement of the Error protocol, which means it's not a customization point. You need to actually conform to LocalizedError and provide a valid 'errorDescription' instead.
>>
>> (It's too bad that your second test works at all, since MyError doesn't conform to LocalizedError. Unfortunately NSError does conform to LocalizedError, and all Errors can be bridged to NSError.)
>>
>> If you're interested, you can find more information about the design in its proposal, SE-0112 <https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md>.
>>
>> Hope this helps,
>> Jordan
>>
>>
>>> On Feb 28, 2017, at 12:54, Jon Shier via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>>
>>> Swifters:
>>> I have a custom error enum:
>>>
>>> enum MyError: Error {
>>>
>>> case network(error: Error)
>>> case json(error: Error)
>>> case value(error: Error)
>>>
>>> var localizedDescription: String {
>>> switch self {
>>> case let .network(error): return error.localizedDescription
>>> case let .json(error): return error.localizedDescription
>>> case let .value(error): return error.localizedDescription
>>> }
>>> }
>>>
>>> }
>>>
>>> However, the localizedDescription output is odd to me. When the value is treated as:
>>>
>>> Error: po error.localizedDescription
>>> "The operation couldn’t be completed. (MyApp.MyError error 1.)”
>>>
>>> LocalizedError: po (error as! LocalizedError).localizedDescription
>>> "The operation couldn’t be completed. (MyApp.MyError error 1.)”
>>>
>>> MyError: Error: po (error as! MyError).localizedDescription
>>> "JSON could not be serialized because of error:\nThe data couldn’t be read because it isn’t in the correct format."
>>>
>>> Shouldn’t my implementation of localizedDescription take precedence in all cases here? (This is Xcode 8.3b3).
>>>
>>>
>>>
>>> Jon
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users at swift.org <mailto:swift-users at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170228/cdd983b9/attachment.html>
More information about the swift-users
mailing list