> On Dec 24, 2015, at 2:56 AM, Colin Cornaby <[email protected]> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
