NSFileCoordinator在Swift中的奇怪案例

Question

尽管NSFileCoordinator是一个非常重要的类，但它似乎还没有获得任何seems认证。它没有被赋予任何async选项；您必须提供一个完成处理程序。此外，它需要一个NSErrorPointer而不是标记为throws，并且在完成处理程序中不能引用切入点：

let url = URL(fileURLWithPath: "fakepath")
var error: NSError?
NSFileCoordinator().coordinate(readingItemAt: url, error: &error) { url in
    let theError = error
    print(theError as Any)
}

这会导致一个错误：“同时访问error，但是修改需要独占访问。”

如果我无法从块内部访问错误，这有什么用？我怎么才能进入它？当然不是在块之后；完成处理程序是异步调用的(因为我们必须等待协调访问是可能的)，所以在块之后，即使实际上存在错误，错误始终是nil。

(我注意到苹果自己的示例代码避免了这个问题，根本不检查它的error变量的值。)

Answer 1

显然，这种方法比我想象的还要奇怪。根据文档，如果有错误，则永远不会调用完成处理程序。因此，在完成处理程序之后检查error是否为非nil值实际上可能有些帮助。

此外，docs还表示，您需要设置一个单独的"sentinel“值，以表示最初的失败，然后将其设置为在完成处理程序中表示成功。因此，规范的架构应该是：

let url = URL(fileURLWithPath: "fakepath")
var failure = true
var error: NSError?
NSFileCoordinator().coordinate(readingItemAt: url, error: &error) { url in
    failure = false
}
if failure {
    print(error as Any)
}

我从来没有见过这个架构被使用过，但这似乎是你应该做的。