存储位置信息

你已经成功初始化Core Data，并将NSManagedObjectContext传递给Tag Location界面。 现在，当用户按下“Done”按钮时，将新的Location对象放入数据存储区。

打开LocationDetailsViewController.swift，添加一个新的实例变量：

var date = Date()

你添加这个变量是因为你需要将当前日期存储到新的Location对象中，因此你需要一个Date对象。

在viewDidLoad()中，将设置dateLabel的文本那一行语句修改为：

dateLabel.text = format(date: date)

这时新的这个变量就被用起来了。

将done方法修改为下面这个样子：

@IBAction func done() {
        let hudView = HudView.hud(inView: navigationController!.view,
                                  animated: true)
        hudView.text = "Tagged"
        // 1
        let location = Location(context: managedObjectContext)
        // 2
        location.locationDescription = descriptionTextView.text
        location.category = categoryName
        location.latitude = coordinate.latitude
        location.longitude = coordinate.longitude
        location.date = date
        location.placemark = placemark
        // 3
        do {
            try managedObjectContext.save()
            afterDelay(0.6) {
                self.dismiss(animated: true, completion: nil)
            }
        } catch {
            fatalError("Error: \(error)")
        }
      }

它的工作原理是这样的。

1、首先，你创建了一个Location的实例。因为这是一个被管理的对象，你必须使用它的init（context :)方法。 你不能只写Location（），这样的话managedObjectContext将不知道新的对象是啥。

2、一旦创建了Location对象的实例，你就可以像使用其他对象一样使用它。 在这里，你将其属性设置为用户在屏幕上输入的内容。

3、现在，你已经有了一个新的Location对象，其属性全部被填充，但如果你在此时查看数据存储区，那么你仍然不会在其中看到任何对象。 直到你使用save（）保存后上下文才会发生。

保存功能会将添加到上下文的任何对象或其内容已更改的任何托管对象永久写入数据存储区。 这就是为什么他们把上下文称为“便笺簿（scratchpad）”。 它的变化会一直持续下去，直到你保存它们。

save（）方法可能由于各种原因而失败，因此你需要捕获潜在的错误。 这是使用Swift的do-try-catch功能完成的。

do-try-catch

有时来自iOS SDK的操作可能会失败并返回某种类型的错误。 你已经见过用于描述这种错误的对象（NSError）。 但是使用Error可能很麻烦，因为它实际上是从Objective-C中借用的东西。

Swift有一个更好的方法来处理错误。 任何可能失败的方法必须在其前面有try关键字。 用try关键字的方法调用必须在do-catch块内。

保存托管对象上下文是一个可能会失败的操作。 这就是为什么你这样写代码：

do {
  try managedObjectContext.save()
  // code that runs when the “try” succeeds . . .
} catch {
  // code that runs when the “try” fails . . .
}

如果出现错误，并且方法失败 - 或者像我们所说的那样“抛出错误”，应用程序将跳过do部分的中所有代码，并立即跳转到catch部分来处理错误。

如果你用使用过支持异常处理的语言，这可能看起来很熟悉。 任何可能引发错误的方法调用都必须写为try methodName（）。 这会很容易找出哪些方法调用引发了错误。

在本教程的后面，你将看到更多的do-try-catch示例。 这是Swift中非常重要的课题，因为没有人喜欢错误。 他们必须被抓住！

运行app，获得一个位置信息，并且添加一段描述后点击Done按钮。

如果一切正常，Core Data会在调试区域打印下列信息：

CoreData: sql: BEGIN EXCLUSIVE ...
CoreData: sql: INSERT INTO ZLOCATION(Z_PK, Z_ENT, Z_OPT, ZCATEGORY,
ZDATE, ZLATITUDE, ZLOCATIONDESCRIPTION, ZLONGITUDE, ZPLACEMARK) VALUES(?,
?, ?, ?, ?, ?, ?, ?, ?)
CoreData: sql: COMMIT
...
CoreData: annotation: sql execution time: 0.0001s

这些是Core Data执行存储新的Location对象到数据库中所执行的SQL语句。

⚠️：Xcode8中不会打印这些信息。

打开Liya软件，刷新ZLOCATION表（点击Go按钮），这时你可以看到表中出现了新的一行。

如果你在表中没有看到任何行，请先按Xcode中的“Stop”按钮退出应用程序。 也可以尝试关闭Liya窗口并打开到数据库的新连接。

如你所见，此表中的列包含Location对象的属性值。 唯一不可读的列是ZPLACEMARK。 其内容已被编码为二进制“blob”数据。 这是因为它是一个转换后的属性，NSCoding协议已经把它的字段转换成二进制数据块。

如果你没有Liya或者你是一个命令行的瘾君子，那么还有另外一种方法来检查数据库的内容。 你可以使用终端应用程序和sqlite3工具，但是不推荐这样做：

处理Core Data错误

将上下文的内容保存到数据存储区，你使用了如下代码：

do {
try managedObjectContext.save() ...
} catch {
  fatalError("Error: \(error)")
}

如果保存有什么问题怎么办？ 在这种情况下，try跳转到catch部分，并调用fatalError（）函数。 这会立即中断掉app，并将用户返回到iPhone的界面。 这对用户来说是非常粗暴的，因此不推荐这样做。

好消息是，如果你试图保存无效的内容，Core Data只会给出一个错误。 换句话说，此时你的app存在BUG。

当然，在开发过程中你可以解决掉所有的bug，所以用户将永远不会遇到任何bug，对吗？ 可悲的是，你永远不会赶上你所有的bug。 有些bug总是会设法溜过去。

坏消息是当Core Data崩溃时，你无法进行过多的干预。 有些地方出现了可怕的bug，比如现在你被无效的数据困住了。 如果app被允许继续运行，事情可能只会变得更糟，因为你不知道app处于什么状态。最后的事就是用户的数据会被破坏掉。

不要用fatalError（）让app崩溃，而是首先告诉用户这个问题，至少他们知道发生了什么。 崩溃仍然是不可避免的，但现在你的用户会知道为什么应用程序突然停止工作。

在本节中，你将添加一个弹出警报来处理这种情况。 当然，这些bug只会在开发过程中发生，但是如果他们确实发生在实际的用户身上，那么你至少应该试着用一点点比较和谐的手段来处理它。

我们通过一些方法来制造点麻烦，看看会发生什么。

打开数据模型文件（DataModel.xcdatamodeld ），然后选择placemark属性。然后取消选择Optional选项。

image.png

这就是说location.placemark不再是一个可选型了。这是Core Data强制执行的一个约束条件。 当你尝试保存为nil的location时，Core Data就会崩溃掉。 所以我们可以利用这一点来进行测试。

运行app。看看效果。。。

你刚刚通过更改placemark属性来变更 了数据模型。 在启动应用程序时，NSPersistentContainer会注意到这一点，并尝试将SQLite数据库执行所谓的“迁移”到更新后的数据模型上。

迁移可能成功，也可能不成功，这依赖于数据存储中当前的内容。 如果之前的placemark为nil，则迁移到新数据模型将失败。 毕竟，新的数据模型不允许为nil的placemark。

此时，你应该可以在调试区域看到如下信息：

reason=Cannot migrate store in-place: Validation error missing attribute
values on mandatory destination attribute, . . . {entity=Location,
attribute=placemark, . . .}

DataModel.sqlite文件对于已更改的数据模型已经无法适应，并且Core Data不能自动解决这个问题。

有两种方法可以解决这个问题：1）简单地删掉Library目录下的DataModel.sqlite文件; 2）从模拟器中删除整个app。

删除DataModel.sqlite文件，以及-shm和-wal文件，然后再次运行app。

我们的重点并不是观看app如何崩溃，而是一定要谨记数据模型变更后，你需要抛弃之前的数据库文件，否则Core Data无法正常初始化。

⚠️：如果NSPersistentContainer迁移失败，并不会全部丢失。 Core Data允许你在使用新数据模型时向你的app发布更新并自己执行迁移。 比起让app崩溃，这种机制允许你将用户现有数据存储的内容转换为新模型。 但是，在开发时还是直接删除掉原有的文件比较简单。

看这样一个场景，点击Get My Location按钮，然后点击Tag Location。 如果你足够快的话，地址解析就会失败，Tag Location界面将会显示：“No Address Found”。 仅当placemark为nil时才会显示这条信息。

可以通过注释掉CurrentLocationViewController.swift中的locationManager（didUpdateLocations）中的self.placemark = p.last！这一行来伪造地址解析过快的现象 。 这会使得看起来没有地址被搜索到，并且placemark的值为 nil。

点击Done按钮来保存新的location对象。

app将会调用fatalError()并且崩溃掉。

image.png

你会在调试区域看到如下信息：

The operation couldn’t be completed . . . NSValidationErrorKey=placemark

意思是placemark属性没有值。因为你把它设置为非可选型了，Core Data无法接受placemark的值为nil。

当然，刚刚看到的只是在Xcode中运行应用程序时才会发生。 当它崩溃时，调试器接管app并指向错误行。 但这不是用户所看到的。

点击Stop按钮关闭app。现在点击模拟器中的app图标，在Xcode之外启动app。 重复相同的操作，使app崩溃。 app将停止运作，并从屏幕上消失。你作为用户什么都看不到。

想象一下，刚刚为你的应用付了99美分（或更多）的用户就会遇到这种情况。 他们会非常困惑，“刚刚发生了什么？！”此时你并没有什么给用户解释的机会，只能接受退款给他们。

发生这种情况时最好显示一个提示。 在用户确认之后，app依然会崩溃，但至少用户知道原因。 （提示消息应该让用户联系你，由你来解释一下怎么回事，这样你至少有机会在下一个版本中修复这个问题。）

打开Functions.swift，并且添加以下代码：

let MyManagedObjectContextSaveDidFailNotification = Notification.Name(
    rawValue: "MyManagedObjectContextSaveDidFailNotification")
func fatalCoreDataError(_ error: Error) {
    print("*** Fatal error: \(error)")
    NotificationCenter.default.post(
        name: MyManagedObjectContextSaveDidFailNotification, object: nil)
}

这里定义了一个新的全局函数来处理致命的Core Data错误。

打开LocationDetailsViewController.swift在done()方法中，替换掉处理错误的代码。

do {
try managedObjectContext.save() ...
} catch {
  fatalCoreDataError(error)
}

这里使用 fatalCoreDataError(error)替换掉了fatalError()。那么这个新的方法到底做了些什么事呢？

它首先使用print（）将错误消息输出到调试区域，因为记录这样的错误总是有用的。 在这之后，执行以下操作：

NotificationCenter.default.post(name: MyManagedObjectContextSaveDidFailNotification, object: nil)

我一直在使用术语“通知(notification)”来表示任何通用事件或消息正在交付，但iOS SDK也有一个名为NotificationCenter的对象（不要和你的手机上的通知中心混淆）。

上面的代码使用NotificationCenter发布通知。 你的app中的任何对象都可以订阅此类通知，如果发生这些通知，NotificationCenter将在这些侦听器对象上调用某个方法。

使用这个官方的通知系统是使你的对象可以相互沟通的另一种方式。 它的方便之处在于，发送通知的对象和接收通知的对象不需要彼此知道任何事情。 发件人只是发送通知，但并不在乎发生了什么事情。 如果有人在听，太好了。 如果没有，那么也无所谓。

UIKit定义了许多可以订阅的标准通知。 例如，有一个通知让你知道，当用户点击Home按钮时，app即将被暂停。

你也可以定义自己的通知，这就是你刚才所做的。 新的通知被称为MyManagedObjectContextSaveDidFailNotification。

思路是，app中有一个地方监听这个通知，弹出一个警报视图，并终止app。 使用NotificationCenter的好处是你的Core Data代码部分不需要关心这些。

无论何时保存发生错误，无论app中的哪一点，fatalCoreDataError（）函数都会发出此通知，因为它相信其他对象正在侦听通知并处理错误。

那么谁来处理这个错误？ app delegate是一个很好的地方。 这是app中顶级的一个对象，你总是保证这个对象是存在的。

在AppDelegate.swift中添加以下方法：

func listenForFatalCoreDataNotifications() {
        // 1
        NotificationCenter.default.addObserver(
            forName: MyManagedObjectContextSaveDidFailNotification,
            object: nil, queue: OperationQueue.main, using: { notification in
                // 2
                let alert = UIAlertController(
                    title: "Internal Error",
                    message:
                    "There was a fatal error in the app and it cannot continue.\n\n"
                        + "Press OK to terminate the app. Sorry for the inconvenience.",
                    preferredStyle: .alert)
                // 3
                let action = UIAlertAction(title: "OK", style: .default) { _ in
                    let exception = NSException(
                        name: NSExceptionName.internalInconsistencyException,
                        reason: "Fatal Core Data error", userInfo: nil)
                    exception.raise()
                }
                alert.addAction(action)
                // 4
                self.viewControllerForShowingAlert().present(alert, animated: true,completion:nil)
                
        })
    }
    // 5
    func viewControllerForShowingAlert() -> UIViewController {
        let rootViewController = self.window!.rootViewController!
        if let presentedViewController =
            rootViewController.presentedViewController {
            return presentedViewController
        } else {
            return rootViewController
        }
    }

我们一步步的来看一下：

1、告诉通知中心，每当发布MyManagedObjectContextSaveDidFailNotification时，都要通知你。

2、创建一个UIAlertController用于展示错误消息。

3、为警报弹窗的OK按钮添加一个操作。处理按钮按下的代码
还是闭包（闭包这些东西无处不在！）。 闭包创建一个NSException对象来终止应用程序，而不是使用fatalError（）。这样的好处是，它提供了更多的信息到日志。

4、最后，展现这个警报弹窗。

5、为了通过present(animated,completion)方法来展示这个警报弹窗，你需要一个当前可见的视图控制器，所以这个方法就自己找了一个。 不幸的是，你不能简单地使用窗口的rootViewController（在这个app中rootViewController就是tab bar controller），因为当Location Dteails界面打开时，它是处于隐藏状态的。

剩下的就是调用一个新的listenForFatalCoreDataNotifications（）方法，以便通知处理程序向NotificationCenter注册。

将以下内容添加到application(didFinishLaunchingWithOptions)中，就在return true语句之前：

listenForFatalCoreDataNotifications()

再次运行app，并尝试在获得街道地址之前标记位置。 现在，app还是会崩溃，但是至少它告诉用户发生了什么事情：

我应该再强调一次，你必须对你的app进行完善的测试，以确保你没有给Core Data任何未验证过的对象。 你需要不惜一切代价避免这些存储错误！

理想情况下，用户不应该看到该警报弹窗，但它必须存在，因为没有任何保证你的app不会有错误。

⚠️：你可以合理地使用managedObjectContext.save（）让Core Data验证用户输入。 并不是说每当存储失败，你都要使app崩溃掉，只有发生哪些不可预期的错误时才会这样做。
除了可选型之外，还有更多的验证设置可以放在实体的属性上。如果你允许你的用户输入这些实体属性，那么最好用save（）去验证一下。如果save（）方法抛出了一个错误，那么用户的任何输入都是无效的，你必须妥善处理这种情况。

打开数据模型文件，重新将placemark属性设置为可选型。

运行app，看看是否一切正常。