Question

我在后台线程中（在应用程序启动后不久）对数据库进行了一些非必要的更改，然后将它们合并到主上下文中。后台线程最终可能会进行大量更改，但我不希望上下文保存在此后台处理中因某些验证错误或某些难以理解的Core Data异常而绊倒;特别是因为我将iCloud与核心数据结合使用，因此用户最终可以获得与之无关的关系。我只是希望应用程序继续运行而不是抛出异常并退出。

在这种情况下，围绕上下文保存@ try- @ catch块是否有意义？这样做有任何性能或内存管理问题吗？

这样的事情：

@try {
        [context performBlockAndWait: ^{
            NSError *error = nil;
            if ([context save:&error]){
                NSLog(@"Child context saved");

                [context.parentContext performBlockAndWait:^{
                    NSError *parentError = nil;
                    if ([context.parentContext save: &parentError]){
                        NSLog(@"Parent context saved");
                    }
                }];
            }
        }];
    } ....

我的应用程序发送给成千上万的客户，所以如果这可能导致更多问题而不是解决，那么事先了解它会很棒。

Answer 1

抛出了什么异常？

由于-[NSManagedObjectContext save:]使用NSError out-parameter模式，我通常会期望它不会抛出。然而，可可的一般模式是异常是“死亡”而不被认为是可以恢复的。

各种系统框架中都有抛出和捕获异常的地方（你可以通过在调试器中设置异常抛出断点来看到） - 我正在看你 Cocoa绑定 - 但一般来说，如果异常冒泡到您的应用程序代码，那么您已经“死在了水中”。

执行此操作是否存在任何性能或内存管理问题？

现在，@try/@catch/@finally的性能损失非常小（并非总是这样）。确实存在内存管理含义（这可能是异常通常在此平台上“死亡”的原因。）如果您使用ARC并通过抛出异常退出范围，则ARC保留的没有发布。如上所述here：

标准的Cocoa约定是异常信号编程器错误，不打算从中恢复。制作代码默认情况下，exception-safe会强制运行严重的运行时和代码对代码的惩罚通常并不关心例外安全。因此，ARC生成的代码默认泄露异常，如果过程将是正常的无论如何立即终止。关心恢复的程序来自例外应该启用该选项。

简而言之，在@try/@catch块中包装上下文保存操作可能没有意义。

围绕NSManagedObjectContext保存尝试捕获是否有帮助？

1 个答案: