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 <[email protected]> wrote: > >> >> On Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution >> <[email protected] <mailto:[email protected]>> 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): > > 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> > <[email protected] <mailto:[email protected]>> wrote: >>> > >>> > Proposal Link: >>> > https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md >>> > >>> > <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 >>> > [email protected] <mailto:[email protected]> >>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
