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 <[email protected]> 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 <[email protected]
>> <mailto:[email protected]>> 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 <[email protected]
>>> <mailto:[email protected]>> 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
>>> [email protected] <mailto:[email protected]>
>>> https://lists.swift.org/mailman/listinfo/swift-users
>>> <https://lists.swift.org/mailman/listinfo/swift-users>
>>
>
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
