[swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

Tue Aug 2 16:28:40 CDT 2016

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 <dgregor at apple.com> wrote:
>>
>>>
>>> On Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution <swift-
>>> evolution at 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-
>>>> evolution at 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 at 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 at 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 at swift.org
>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _________________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160802/53c8fc33/attachment.html>