> 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.
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: ..)
}
…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._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
