1

我有一个 ObjC iOS 应用程序，我在其中存档/取消存档数据。有问题的数据来自配套服务器。每个用户获得一组不同的数据。

虽然我从未收到过用户投诉，但我看到 Crashlytics 在这条线上报告了极少数的崩溃：

NSArray *array = [NSKeyedUnarchiver unarchiveObjectWithFile:path];

崩溃细节：

Fatal Exception: NSInvalidArgumentException
*** -[NSKeyedUnarchiver initForReadingWithData:]: incomprehensible archive (0x62, 0x70, 0x6c, 0x69, 0x73, 0x74, 0x30, 0x30)

崩溃发生在大约 0.002% 的会话中，但在少数未知用户中最常见。

我发现了这个相关问题：Archiving / Unarchiving results in initForReadingWithData incomprehensible archive。讨论为原因提供了两种合理的理论；一个是存档包含字符“bplist”（听起来很合理），另一个涉及存档的大小（不太可能给定典型的数据集大小）。

我正在寻找有关如何检测这种情况并以某种方式避免崩溃的建议。NSKeyedArchiver 似乎没有返回错误的方法 - 失败的存档是崩溃。

理想情况下，我更喜欢一些机制来在问题发生之前检测到问题的根本原因。这个问题的频率并不能证明我编写自己的存档解析器是合理的，也不能证明添加任何将由所有用户执行的疯狂内容的风险是合理的。

我避免@try在练习中遇到障碍。显然这是一种可能。该应用程序读取此存档的频率远高于写入，因此我的想法是@try在写入后尝试读取（在 a 内），如果读取失败，请执行一些操作以将状态详细信息报告给我。我还需要找到另一种方法来为这些用户缓存数据，但这很容易。

4

1 回答 1

0

虽然使用try/catch应该有点少见，但这是一个完全有效的使用案例。由于意外的文件，您的应用程序崩溃是不好的。这是您的应用程序应该处理的事情，并且可以轻松地从中恢复。捕获尝试取消归档坏文件的异常并向用户报告适当的错误或以其他适当的方式处理它。

我在我的一个应用程序中的代码中执行相同的操作，我解压缩用户可以导入应用程序的 zip 文件。用户可能导入了 zip 文件以外的其他内容。所以我用try/catch. 基本上会向用户显示一个错误，catch让他们知道 zip 文件无效。

于 2016-02-03T22:40:40.300 回答