On Dec 19, 2015, at 9:00 PM, Dennis Lysenko via swift-evolution
<[email protected]> wrote:
>
> Charles,
>
> While I agree it's unfortunate that there isn't much interop between
> ErrorType and NSError, the decision from the core team to make ErrorType an
> empty protocol seems to have been a premeditated one. I would love to have
> someone on the core team respond here in my stead, but I'll try and present
> my side of it.
>
> I have a lot of errors that come up internally in my app's workings. I
> subscribe to Swift's error handling rationale regarding recoverable errors.
> For example, my internal networking library has a NoInternetError which never
> needs to be presented using built-in cocoa error presentation, but instead
> has a different presentation scheme for each different context (e.g. if it
> happened while loading a tableview, it shows up as the placeholder text. if
> it happened in response to a user action, it displays an alert.) I,
> therefore, strongly disagree with adding any extra members to the ErrorType
> protocol: it's cruft that will never be of use to me.
>
> Now, this is the part that I'm not sure about and I might be corrected by
> someone from the core team: It seems that part of the rationale for
> introducing the general ErrorType is to move away from NSError. NSError is
> antiquated and carries information that is often not even used (take a survey
> of 100 swift programmers, and maybe 40 of them will care to tell you what an
> error domain is).
I agree that our interop with NSError is unsatisfactory and should be a lot
better. We had some discussions about improvements that could be made in this
space late in the Swift 2 design cycle, but I’ve since paged them out. John
McCall would be the best person to talk to about this, he drove much of the
Swift 2 error handling design.
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
