Charles:
Foundation error reporting is based on NSError, nothing else. In none
of my apps have I used my own NSError’s and in the few frameworks I use or
maintain, few use NSError, and then only to avoid having to declare a custom
error type, to make the API perhaps a bit more familiar to consumers. All your
concern about conversion to and from NSErrors is largely irrelevant to anyone
who isn’t using Swift from Objective-C on a regular basis. It’s utterly
irrelevant to the native Swift programmer. I’m not sure where your issue about
presenting non-NSError’s come from, since the mechanisms to present an error
would have to be custom written no matter the error type. The drawbacks I see
with exposing NSError’s properties on every ErrorType is that those properties
are only there as a hack to interoperate with NSError. Really they’d go away as
Swift evolves it’s own default error representation, or language leaves it to
developer to build their own.
Essentially, I think that if you want to improve ErrorType, formalizing
its relationship to NSError is the wrong way. NSErrors are not good error
representations, especially in Swift, and we should move away from them as soon
as possible.
Jon
> On May 14, 2016, at 1:46 AM, Charles Srstka <[email protected]> wrote:
>
> On May 14, 2016, at 12:19 AM, Jon Shier via swift-evolution
> <[email protected]> wrote:
>>
>> Charles:
>> I appreciate the attempt to minimize a current pain point and I agree
>> on most of your analysis of the current NSError bridging but I think your
>> proposal is fundamentally flawed. By forcing the core error type to have
>> properties from NSError, you’re essentially finalizing what all error types
>> in Swift should look like. Error domains, codes, and info dictionaries are
>> not Swift, and forcing every error produced in Swift to have those
>> properties is a regression from the freedom ErrorType has given us. No
>> native Swift error type I’ve seen so far has chosen to replicate those
>> properties, and for good reason: they are a relic of C which have no place
>> in Swift. There are far better error designs out there. If you want to
>> propose a strong type of error for Swift, go ahead, but it should be
>> thoroughly inspired by Swift, not driven by a desire to ease bridging to
>> NSError.
>
> Nothing is forced at all, any more than they are currently. The thing to
> remember is that ErrorProtocol *already* defines properties for error domains
> and codes:
>
> public protocol ErrorProtocol {
> var _domain: String { get }
> var _code: Int { get }
> }
>
> Thus, the statement that no native Swift error type has these properties
> could not be farther from the truth, as in fact, *every* Swift error type has
> these two properties (and several prominent error types in the standard
> library provide specific values for these properties as well; POSIXError and
> NSCocoaError come to mind). The reason many Swift developers haven’t noticed
> this fact is because the properties have default implementations, which means
> that if you don’t have a specific need to override them, you never have to
> deal with them. Adding a userInfo property, which also has a default
> implementation (returning an empty dictionary), will therefore not take away
> any of the freedom of ErrorType, or really cause any difference at all to a
> developer who is not interested in providing userInfo values on his/her
> errors.
>
> What the proposal will do, on the other hand, is give a lot of that freedom
> *back*. The fact of the matter is that the entire error-reporting mechanism
> is currently based on NSError. If you have a method which can return an
> error, and you want that error to be presentable to the user in a form more
> expressive than “MyApp.MyErrorType error 2”, you currently have only two
> choices: 1) create some home-grown mechanism to convert your errors to
> NSErrors, and be sure to invoke that mechanism when throwing from any method
> that could conceivably be called from Objective-C, or 2) just use NSErrors
> all the way down, foregoing the use of native Swift errors at all. My
> proposal would allow the free and unlimited use of Swift native errors
> everywhere errors are a possibility with no drawbacks, since if an error
> needed to be made into a human-readable form, this would only be a simple
> matter of defining a userInfo property on the error type, even if much later
> down the line, and would not necessitate adding an NSError conversion at
> every throw-site in the program. Indeed, this proposal will actually *remove*
> a lot of NSError-based thinking from the actual code, and localize all such
> considerations to a relatively small area, to such extent as they are needed.
>
> Charles
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
