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
> <den...@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@swift.org <mailto:swift-users@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 <eliacer...@gmail.com
>> <mailto:eliacer...@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@swift.org <mailto:swift-users@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-users
>> <https://lists.swift.org/mailman/listinfo/swift-users>
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
