尝试捕获 NSManagedObjectContext 保存是否有帮助？答案

【问题标题】：Does it help to have a try-catch around NSManagedObjectContext save?尝试捕获 NSManagedObjectContext 保存是否有帮助？
【发布时间】：2014-05-18 22:35:36
【问题描述】：

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

在这种情况下，在上下文保存周围有一个@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");
                    }
                }];
            }
        }];
    } ....

我的应用交付给了成千上万的客户，因此如果提前知道这是否会导致比它解决的问题更多的问题，那就太好了。

【问题讨论】：

除非你能以安全的方式从异常中恢复，否则捕获它并没有多大意义。

标签： core-data grand-central-dispatch nsmanagedobjectcontext

【解决方案1】：

抛出了哪些异常？

由于-[NSManagedObjectContext save:] 使用NSError 外参数模式，我通常希望它不会抛出。但是，Cocoa 中的一般模式是异常是“死亡”并且不被认为是可恢复的。

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

这样做是否存在任何性能或内存管理问题？

如今，@try/@catch/@finally 的性能损失非常小（并非总是如此）。可以肯定的是内存管理的影响（这可能是为什么异常在这个平台上通常是“死亡”的原因。）如果你使用 ARC 并通过抛出异常的方式退出范围，ARC 所采取的保留是没有发布。如here所述：

标准的 Cocoa 约定是异常信号程序员错误并且不打算从中恢复。制作代码默认情况下的异常安全将强加严重的运行时和代码大小对通常实际上并不关心的代码的惩罚异常安全。因此，ARC 生成的代码默认泄漏例外，如果该过程将是这样就好了无论如何立即终止。关心恢复的程序 from exceptions 应该启用该选项。

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

【讨论】：