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

[Charles Srstka]

> On Dec 24, 2015, at 2:56 AM, Colin Cornaby <colin.cornaby at mac.com> wrote:
> 
>> And my two cents is:
>> 
>> NSError is antiquated, and enums conforming to ErrorType, with associated types on the case values, are much better. They are cleaner, they are easier to use, and they are nicer to look at.
> 
> And I still think that’s a platform choice. If a platform wants to define it’s errors as a Swift enum, or if a developer is defining their own independent platform, that’s a semi-reasonable thing to do. But I think trying to force all the platforms (Apple and non-Apple) into an enum shaped box for cross platform Swift is going to be problematic. If the authors of Cocoa want to begin defining all their errors as enums, the ball is certainly in their court, but it doesn’t feel right to me to promote that up to a language concern.
> 
> Before multiplatform Swift, I was totally onboard with the idea of supercharging ErrorType, but the more I think about it, and the more I look at lower level stuff that we could begin using Swift for on other platforms, the more I think having larger error types needs to be a decision made by the host platform API on a case by case basis. And I’m not convinced an enum is an appropriate error tool for all cases, even though it is certainly appropriate for a lot of cases.

That’s a bit of a non-sequitur, though. Since ErrorType is a protocol, it can be anything. It can be an enum, a struct, a class, whatever you want. No one’s forcing enums, or anything really; enum just happens to be, in my opinion, the nicest of these to use. Someone else in the thread disagreed and preferred structs. That’s all fine; the whole point of ErrorType is that you can use what you want; there should just be a nicer way to bridge these things, in whatever form you prefer them, to NSError, so that we’re not forcing anyone into an NSError-shaped box.

> I do think there are some weird sharp edges around NSError/ErrorType that aren’t specific to NSError, and will continue cutting people’s fingers on other platforms (for example, if I had a C API that defined it’s own error type as a struct, I’d be having a lot of the same problems.) I haven’t been able to come up with any reasonable ideas though that would fix everything.
> 
> One thing I think could be done is that NSError could somehow be made to conform to RawRepresentable, which would then take care of a lot of this.
> 
> The code could then become:
> enum MyError: NSError {
>     case JustFouledUp(domain: .., code: .., userInfo: ..)
>     case CouldntDealWithFile(domain: .., code: .., userInfo: ..)
>     case CouldntDealWithSomeValue(domain: .., code: .., userInfo: ..)
> }

This is impossible, because enums with raw values can’t have cases with arguments. Try it: it won’t compile.

> …with no need for the functions to implement to provide out the other usual data. I know some consider the NSError initializers kind of awful, that’s something that could be dealt with at the NSError API level. I actually think the above looks a lot cleaner, although I know I skipped over some of the mess with ellipsis. And API developers don’t have to implement manual, hand rolled bridging.
> 
> This seems cleanest to me, and would carry going forward with Error in OSS Foundation.

Honestly, I can’t imagine anyone *not* finding the NSError initializers awful. It’s a truly cringe-worthy API. Beyond that, forcing every error object, even ones that are never touching Obj-C code at all, to be backed by a bulky NSError object is pretty unreasonable, IMO. I’d much prefer to store the error data using lean and mean Swift-native constructs, and bridge to NSError only when it’s needed to interact with AppKit/UIKit.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151224/73474fb7/attachment.html>