You're assuming that every error passed to that method is a CKError. The documentation does not claim that to be true, so it's quite plausible that you might get other errors that are simply passed through.
-Kevin On Tue, Aug 2, 2016, at 02:19 PM, Jon Shier via swift-evolution wrote: > Thanks Doug. I missed the rename, as earlier points still referred to > ErrorProtocol. In regards to the CloudKit errors, I appreciate the > strongly typed CKError, but why not have the methods return that type > directly? Every usage of these methods is going to require such a > cast, so why require it in the first place? I don’t understand what > advantage erasing the strongly type error that was just created has > when the developer will just have to bring it right back. Or is this > just a first implementation? > > > Jon > >> On Aug 2, 2016, at 4:20 PM, Douglas Gregor <dgre...@apple.com> wrote: >> >>> >>> On Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution <swift- >>> evolut...@swift.org> wrote: >>> >>> I’m not sure where to put such feedback, but the ErrorProtocol to >>> Error rename that accompanied the implementation of this proposal is >>> very, very painful. It completely eliminates the very useful ability >>> to embed an associated Error type inside other types, as those types >>> now conflict with the protocol. Also, was this rename accompanied by >>> an evolution proposal? It seems like the change was just made when >>> this proposal was implemented. >> >> The rename was part of the proposal, in bullet #5 of the proposed >> solution (which, amusing, pastes as bullet #1 below): >> >> 1. Rename ErrorProtocol to Error: once we've completed the bridging >> story, Error becomes the primary way to work with error types in >> Swift, and the value type to which NSError is bridged: >> func handleError(_ error: Error, userInteractionPermitted: Bool) >> >> >>> Also, the adoption of this proposal by the Cocoa(Touch) frameworks >>> as seen in Xcode 8 beta 4 has made asynchronous error handling quite >>> a bit more arduous. For example, the CKDatabase method >>> fetch(withRecordID recordID: CKRecordID, completionHandler: >>> (CKRecord?, Error?) -> Void) returns an `Error` now, meaning I have >>> to cast to the specific `CKError` type to get useful information out >>> of it. Is this just an unfortunate first effort that will be fixed, >>> or is this the expected form of these sorts of APIs after this >>> proposal? >> >> Prior to this proposal, you would have had to check the domain >> against CKErrorDomain anyway to determine whether you’re looking at a >> CloudKit error (vs. some other error that is passing through >> CloudKit), so error bridging shouldn’t actually be adding any work >> here—although it might be making explicit work that was already done >> or should have been done. Once you have casted to CKError, you now >> have typed accessors for information in the error: >> >> extension CKError { >> /// Retrieve partial error results associated by item ID. >> public var partialErrorsByItemID: [NSObject : Error]? { >> return userInfo[CKPartialErrorsByItemIDKey] as? [NSObject : >> Error] >> } >> >> /// The original CKRecord object that you used as the basis for >> /// making your changes. >> public var ancestorRecord: CKRecord? { >> return userInfo[CKRecordChangedErrorAncestorRecordKey] as? >> CKRecord >> } >> >> /// The CKRecord object that was found on the server. Use this >> /// record as the basis for merging your changes. >> public var serverRecord: CKRecord? { >> return userInfo[CKRecordChangedErrorServerRecordKey] as? CKRecord >> } >> >> /// The CKRecord object that you tried to save. This record is >> based >> /// on the record in the CKRecordChangedErrorAncestorRecordKey key >> /// but contains the additional changes you made. >> public var clientRecord: CKRecord? { >> return userInfo[CKRecordChangedErrorClientRecordKey] as? CKRecord >> } >> >> /// The number of seconds after which you may retry a request. This >> /// key may be included in an error of type >> /// `CKErrorServiceUnavailable` or `CKErrorRequestRateLimited`. >> public var retryAfterSeconds: Double? { >> return userInfo[CKErrorRetryAfterKey] as? Double >> } >> } >> - Doug >> >>> >>> >>> >>> Jon Shier >>> >>> >>>> On Jul 12, 2016, at 8:44 AM, Shawn Erickson via swift-evolution <swift- >>>> evolut...@swift.org> wrote: >>>> >>>> Thanks for the effort on the proposal and discussion and thanks to >>>> those working in the implementation. >>>> >>>> -Shawn >>>> On Tue, Jul 12, 2016 at 12:25 AM Charles Srstka via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>>> Wow, thanks! I’m delighted that Apple found this improvement to be >>>>> worth inclusion in Swift 3. This will truly make the language much >>>>> nicer to use with the Cocoa frameworks. >>>>> >>>>> Thanks! >>>>> >>>>> Charles >>>>> >>>>> > On Jul 11, 2016, at 11:19 PM, Chris Lattner via swift-evolution >>>>> > <swift-evolution@swift.org> wrote: >>>>> > >>>>> > Proposal Link: >>>>> > https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md >>>>> > >>>>> > The review of "SE-0112: Improved NSError Bridging" ran from June >>>>> > 30 ... July 4, 2016. The proposal has been *accepted*: >>>>> > >>>>> > The community and core team agree that this proposal is a huge >>>>> > step forward that enriches the experience working with and >>>>> > extending the Cocoa NSError model in Swift. The core team >>>>> > requests one minor renaming of >>>>> > "attemptRecovery(optionIndex:andThen:)" to >>>>> > "attemptRecovery(optionIndex:resultHandler:)”. It also >>>>> > discussed renaming CustomNSError and RecoverableError, but >>>>> > decided to stay with those names. >>>>> > >>>>> > Thank you to Doug Gregor and Charles Srstka for driving this >>>>> > discussion forward, and for Doug Gregor taking the charge on the >>>>> > implementation effort to make this happen for Swift 3! >>>>> > >>>>> > -Chris Lattner >>>>> > Review Manager >>>>> > >>>>> > _______________________________________________ >>>>> > swift-evolution mailing list >>>>> > swift-evolution@swift.org >>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution > _________________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution