[swift-evolution] [Proposal idea] Improved interop for ErrorType->NSError

[Chris Lattner]

On Dec 19, 2015, at 9:00 PM, Dennis Lysenko via swift-evolution <swift-evolution at swift.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151221/04193a19/attachment.html>