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@swift.org> wrote:
>
>>
>> On Aug 5, 2016, at 7:36 PM, Erica Sadun <er...@ericasadun.com
>> <mailto:er...@ericasadun.com>> wrote:
>>
>> On Aug 5, 2016, at 8:10 PM, Kevin Ballard <ke...@sb.org
>> <mailto:ke...@sb.org>> wrote:
>>>
>>>>
>>>> On Aug 5, 2016, at 5:16 PM, Erica Sadun <er...@ericasadun.com
>>>> <mailto:er...@ericasadun.com>> wrote:
>>>>
>>>>
>>>>> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>
>>>>>>
>>>>>> On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evolution
>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
