[swift-users] Asynchronous error recovering with RecoverableError

Tue Mar 28 17:36:03 CDT 2017

New start task: https://bugs.swift.org/browse/SR-4405 <https://bugs.swift.org/browse/SR-4405> Add @escaping to RecoverableError.attemptRecovery


> On Mar 28, 2017, at 3:31 PM, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 
>> On Mar 28, 2017, at 11:21 AM, Michael Ilseman <milseman at apple.com <mailto:milseman at apple.com>> wrote:
>> 
>> CC Doug Gregor, who git blame tells me wrote this part.
>> 
>> Doug, this slightly predates noescape-by-default. Is this a bug or as intended?
> 
> It’s a bug; the point here is that we can do recovery asynchronously, so it should be @escaping. We missed the annotation when noescape-by-default landed.
> 
> 	- Doug
> 
>> 
>> 
>>> On Mar 28, 2017, at 8:49 AM, Elia Cereda via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>> 
>>> Hi Dennis,
>>> 
>>> Thanks for your answer. I can see that my message needs some more context: RecoverableError is a protocol in the standard library that can be implemented to opt in to the error recovery mechanism available on macOS. attemptRecovery(optionIndex, resultHandler:) is one of the methods that have to be implemented to conform to the protocol.
>>> 
>>> Here you can find the other ones:
>>> 
>>> /// Describes an error that may be recoverable by presenting several
>>> /// potential recovery options to the user.
>>> public protocol RecoverableError : Error {
>>> 
>>>     /// Provides a set of possible recovery options to present to the user.
>>>     public var recoveryOptions: [String] { get }
>>> 
>>>     /// Attempt to recover from this error when the user selected the
>>>     /// option at the given index. This routine must call handler and
>>>     /// indicate whether recovery was successful (or not).
>>>     ///
>>>     /// This entry point is used for recovery of errors handled at a
>>>     /// "document" granularity, that do not affect the entire
>>>     /// application.
>>>     public func attemptRecovery(optionIndex recoveryOptionIndex: Int, resultHandler handler: (Bool) -> Swift.Void)
>>> 
>>>     /// Attempt to recover from this error when the user selected the
>>>     /// option at the given index. Returns true to indicate
>>>     /// successful recovery, and false otherwise.
>>>     ///
>>>     /// This entry point is used for recovery of errors handled at
>>>     /// the "application" granularity, where nothing else in the
>>>     /// application can proceed until the attempted error recovery
>>>     /// completes.
>>>     public func attemptRecovery(optionIndex recoveryOptionIndex: Int) -> Bool
>>> }
>>> 
>>> As you can see, there are two attemptRecovery methods. In my mind the first one was meant to be used for asynchronous operations, where you run some recovering code in background and then report its result back to the caller.
>>> 
>>> The problem is that the handler is not marked as @escaping and as such it can only be used inside the body of attemptRecovery. I was wondering if this was an oversight from the stdlib team or if this was a deliberate design decision.
>>> 
>>> I just saw that the method is still not marked as @escaping in master (https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift#L105 <https://github.com/apple/swift/blob/master/stdlib/public/SDK/Foundation/NSError.swift#L105>), so I’d like to know what its intended use case is, since the obvious one (asynchronous recovery) is prevented by the missing annotation.
>>> 
>>> Thanks,
>>> Elia Cereda
>>> 
>>>> Il giorno 28 mar 2017, alle ore 17:33, Dennis Weissmann <dennis at dennisweissmann.me <mailto:dennis at dennisweissmann.me>> ha scritto:
>>>> 
>>>> Hey Elia,
>>>> 
>>>> I'm currently on mobile and don't really know what you're talking about (what is RecoverableError?) but you say it's a block, and if the closure is optional, it is @escaping by default.
>>>> 
>>>> Did you see https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html <https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160905/003185.html>
>>>> 
>>>> - Dennis
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> On 23. Mar 2017, at 10:07 AM, Elia Cereda via swift-users <swift-users at swift.org <mailto:swift-users at swift.org>> wrote:
>>>> 
>>>>> I'd like to bump this issue, since it has been some time and it hasn't been addressed.
>>>>> 
>>>>> Thanks,
>>>>> Elia Cereda
>>>>> 
>>>>> Il giorno 03 mar 2017, alle ore 21:33, Elia Cereda <eliacereda at gmail.com <mailto:eliacereda at gmail.com>> ha scritto:
>>>>> 
>>>>>> I’m wondering why the resultHandler block on RecoverableError.attemptRecovery(optionIndex, resultHandler:) is not marked @escaping?
>>>>>> 
>>>>>> I’m trying to invoke some recovering code that executes asynchronously, then reports if it was successful or not and I thought that this was the right strategy. As far as I can tell, without @escaping that method loses all it’s purpose and becomes essentially equivalent to attemptRecovery(optionIndex:).
>>>>>> 
>>>>>> So, I’d like to ask.
>>>>>> 1. Is it a bug or that method is non-escaping on purpose?
>>>>>> 2. If it is a bug, is there a workaround that can be applied pending a fix in a future version of Swift?
>>>>>> 3. If it was a deliberate decision, what's the supported method of asynchronously invoking error recovery code?
>>>>>> 
>>>>>> Seeing that this wasn’t changed in Xcode 8.3b2, I think it unlikely that this was an oversight.
>>>>>> 
>>>>>> Thanks,
>>>>>> Elia Cereda
>>>>>> 
>>>>> _______________________________________________
>>>>> swift-users mailing list
>>>>> swift-users at swift.org <mailto:swift-users at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
>>> 
>>> _______________________________________________
>>> swift-users mailing list
>>> swift-users at swift.org <mailto:swift-users at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170328/30a115c8/attachment.html>