处理CloudKit错误 [英] Handling CloudKit Errors
问题描述
我正在寻找在Swift处理CloudKit错误的一般建议，并且无法在线查找好的示例。这是我想知道的事情：
1）每次出现错误的可能性时，我应该考虑每一个错误类型，还是不是真的有必要？ 2）我已经看到，处理CloudKit错误的一种常见方法是在错误消息提供的时间间隔后重试执行该操作。这个重试是否基本上是我所有错误的标准程序？
3）做不同的CloudKit操作（保存，提取等）会产生不同类型的错误，或者是在那里一个标准的CloudKit错误？
提前感谢！我正在寻找有关如何处理CloudKit的错误处理的一般信息，因为我不太确定从哪里开始。
是的，你想检查每个cloudkit调用的错误。苹果在与Cloudkit相关的WWDC视频中强调了这一点。
当您检测到错误时，您所做的操作会有很大差异。重试有时是一种选择，但有时候不合适。如果您正在使用批处理操作，则重试可能需要一些额外的工作来提取出错的记录。所以，是的，你有时可能要重试，但不可以，你可能不会自动重试每个失败的操作。
有一组错误，定义在 CKError.h 。但是，你并不总是只得到一个CKError。有时，特别是使用 CKErrorPartialFailure 时，您会收到一个包含嵌套错误的顶级错误，您也必须解开它们。在IOS 10中， CKError.h 中的错误列表如下所示：
typedef NS_ENUM（NSInteger，CKErrorCode）{
CKErrorInternalError = 1，/ * CloudKit.framework遇到错误。这是一个不可恢复的错误。 * /
CKErrorPartialFailure = 2，/ *某些项目失败，但操作成功。在userInfo字典中查看CKPartialErrorsByItemIDKey以获取更多详细信息。 * /
CKErrorNetworkUnavailable = 3，/ *网络不可用* /
CKErrorNetworkFailure = 4，/ *网络错误（可用，但CFNetwork给我们一个错误）* /
CKErrorBadContainer = 5，/ *未配置或未经授权的集装箱。尝试在重试操作之前配置容器。 * /
CKErrorServiceUnavailable = 6，/ *服务不可用* /
CKErrorRequestRateLimited = 7，/ *客户端正在限速* /
CKErrorMissingEntitlement = 8，/ *缺少权利* /
CKErrorNotAuthenticated = 9，/ *未通过身份验证（无需登录，无用户记录）* /
CKErrorPermissionFailure = 10，/ *访问失败（保存，提取或shareAccept）* /
CKErrorUnknownItem = 11，/ *记录不存在* /
CKErrorInvalidArguments = 12，/ *客户端请求（坏记录图，格式错误的谓词）* /
CKErrorResultsTruncated NS_DEPRECATED（10_10，10_12，8_0，10_0，将不能返回）= 13，
CKErrorServerRecordChanged = 14，/ *记录被拒绝，因为服务器上的版本不同* /
CKErrorServerRejectedRequest = 15，/ *服务器拒绝了此请求。这是一个不可恢复的错误* /
CKErrorAssetFileNotFound = 16，/ *未找到资源文件* /
CKErrorAssetFileModified = 17，/ *保存资源文件内容* /
CKErrorIncompatibleVersion = 18，/ * App版本小于允许的最小版本* /
CKErrorConstraintViolation = 19，/ *服务器拒绝了请求，因为与唯一字段有冲突。 * /
CKErrorOperationCancelled = 20，/ * CKOperation被明确取消* /
CKErrorChangeTokenExpired = 21，/ *以前的ServerChangeToken值太旧，客户端必须从头重新同步* /
CKErrorBatchRequestFailed = 22，/ *此批处理中的一个项目在具有原子更新的区域中失败，因此整个批次都被拒绝。 * /
CKErrorZoneBusy = 23，/ *服务器太忙，无法处理此区域操作。在几秒钟内再次尝试操作。 * /
CKErrorBadDatabase = 24，/ *无法在给定的数据库上完成操作。可能由于尝试修改公共数据库中的区域而导致的。 * /
CKErrorQuotaExceeded = 25，/ *保存记录将超过配额* /
CKErrorZoneNotFound = 26，/ *服务器上不存在指定的区域* /
CKErrorLimitExceeded = 27，/ *对服务器的请求过大。将此请求重试为较小的批次。 * /
CKErrorUserDeletedZone = 28，/ *用户通过设置UI删除了该区域。在尝试重新上传任何数据到该区域之前，您的客户端应该删除其本地数据或提示用户。 * /
CKErrorTooManyParticipants NS_AVAILABLE（10_12，10_0）= 29，/ *由于参与者参与人数太多，无法保存共享* /
CKErrorAlreadyShared NS_AVAILABLE（10_12，10_0）= 30，/ *记录/共享无法保存，这样做会导致多个共享中存在的记录层次结构* /
CKErrorReferenceViolation NS_AVAILABLE（10_12，10_0）= 31，/ *记录的父或共享引用的目标是未找到* /
CKErrorManagedAccountRestricted NS_AVAILABLE（10_12，10_0）= 32，/ *由于受管理帐户限制，请求被拒绝* /
CKErrorParticipantMayNeedVerification NS_AVAILABLE（10_12，10_0）= 33，/ *共享元数据不能确定，因为用户不是分享的成员。邀请与会者参加电子邮件地址或电话号码与任何iCloud帐户无关。如果用户可以通过系统共享接口UI将其中一个电子邮件地址或电话号码与其iCloud帐户关联，则用户可以加入该共享。在此共享URL上调用UIApplication的openURL以让用户尝试验证其信息。 * /
} NS_ENUM_AVAILABLE（10_10，8_0）;
在开发和测试应用程序时，一种方法是检查每个cloudkit操作错误，如果检测到，则启动NSAssert以停止应用程序。然后，检查错误，底层错误和上下文以确定它为什么失败以及您需要做什么。很可能，随着时间的推移，您会看到常见的模式出现，然后您可以考虑构建一个通用错误处理程序。
I am looking for general advice on handling CloudKit errors in Swift and am having trouble finding good examples online. Here are the things I'm wondering:
1) Should I account for every single error type each time the possibility for an error arises, or is that not really necessary?
2) I have read that one common way of handling CloudKit errors is by retrying to execute the operation after the time interval the error message provides. Should this retry basically be my standard procedure for all errors?
3) Do different CloudKit operations (save, fetch, etc.) produce different types of errors, or is there one standard set of CloudKit errors?
Thanks in advance! I'm just looking for general info on how to go about tackling error handling with CloudKit because I'm not really sure where to start.
Yes, you want to check every cloudkit call for errors. Apple stresses this point in the cloudkit-related WWDC videos.
What you do when you detect an error varies greatly. Retry is sometimes an option, but sometimes not appropriate. If you're using batch operations, retrying may require some additional work to extract the just the records that failed. So, yes you may sometimes want to retry, but no, you probably won't automatically retry every operation that fails.
There is one set of errors, defined in CKError.h. But, you don't always just get a CKError. Sometimes, especially with CKErrorPartialFailure, you get a top-level error that contains nested errors that you also have to unwrap. As of IOS 10, the list of errors in CKError.h looks like:
typedef NS_ENUM(NSInteger, CKErrorCode) {
CKErrorInternalError = 1, /* CloudKit.framework encountered an error. This is a non-recoverable error. */
CKErrorPartialFailure = 2, /* Some items failed, but the operation succeeded overall. Check CKPartialErrorsByItemIDKey in the userInfo dictionary for more details. */
CKErrorNetworkUnavailable = 3, /* Network not available */
CKErrorNetworkFailure = 4, /* Network error (available but CFNetwork gave us an error) */
CKErrorBadContainer = 5, /* Un-provisioned or unauthorized container. Try provisioning the container before retrying the operation. */
CKErrorServiceUnavailable = 6, /* Service unavailable */
CKErrorRequestRateLimited = 7, /* Client is being rate limited */
CKErrorMissingEntitlement = 8, /* Missing entitlement */
CKErrorNotAuthenticated = 9, /* Not authenticated (writing without being logged in, no user record) */
CKErrorPermissionFailure = 10, /* Access failure (save, fetch, or shareAccept) */
CKErrorUnknownItem = 11, /* Record does not exist */
CKErrorInvalidArguments = 12, /* Bad client request (bad record graph, malformed predicate) */
CKErrorResultsTruncated NS_DEPRECATED(10_10, 10_12, 8_0, 10_0, "Will not be returned") = 13,
CKErrorServerRecordChanged = 14, /* The record was rejected because the version on the server was different */
CKErrorServerRejectedRequest = 15, /* The server rejected this request. This is a non-recoverable error */
CKErrorAssetFileNotFound = 16, /* Asset file was not found */
CKErrorAssetFileModified = 17, /* Asset file content was modified while being saved */
CKErrorIncompatibleVersion = 18, /* App version is less than the minimum allowed version */
CKErrorConstraintViolation = 19, /* The server rejected the request because there was a conflict with a unique field. */
CKErrorOperationCancelled = 20, /* A CKOperation was explicitly cancelled */
CKErrorChangeTokenExpired = 21, /* The previousServerChangeToken value is too old and the client must re-sync from scratch */
CKErrorBatchRequestFailed = 22, /* One of the items in this batch operation failed in a zone with atomic updates, so the entire batch was rejected. */
CKErrorZoneBusy = 23, /* The server is too busy to handle this zone operation. Try the operation again in a few seconds. */
CKErrorBadDatabase = 24, /* Operation could not be completed on the given database. Likely caused by attempting to modify zones in the public database. */
CKErrorQuotaExceeded = 25, /* Saving a record would exceed quota */
CKErrorZoneNotFound = 26, /* The specified zone does not exist on the server */
CKErrorLimitExceeded = 27, /* The request to the server was too large. Retry this request as a smaller batch. */
CKErrorUserDeletedZone = 28, /* The user deleted this zone through the settings UI. Your client should either remove its local data or prompt the user before attempting to re-upload any data to this zone. */
CKErrorTooManyParticipants NS_AVAILABLE(10_12, 10_0) = 29, /* A share cannot be saved because there are too many participants attached to the share */
CKErrorAlreadyShared NS_AVAILABLE(10_12, 10_0) = 30, /* A record/share cannot be saved, doing so would cause a hierarchy of records to exist in multiple shares */
CKErrorReferenceViolation NS_AVAILABLE(10_12, 10_0) = 31, /* The target of a record's parent or share reference was not found */
CKErrorManagedAccountRestricted NS_AVAILABLE(10_12, 10_0) = 32, /* Request was rejected due to a managed account restriction */
CKErrorParticipantMayNeedVerification NS_AVAILABLE(10_12, 10_0) = 33, /* Share Metadata cannot be determined, because the user is not a member of the share. There are invited participants on the share with email addresses or phone numbers not associated with any iCloud account. The user may be able to join the share if they can associate one of those email addresses or phone numbers with their iCloud account via the system Share Accept UI. Call UIApplication's openURL on this share URL to have the user attempt to verify their information. */
} NS_ENUM_AVAILABLE(10_10, 8_0);
One approach, while you're developing and testing the app, is to check every cloudkit operation for an error, and if detected, fire an NSAssert to stop the app. Then, examine the error, underlying errors and context to determine why it failed and what you need to do about it. Most likely, over time, you'll see common patterns emerge and you can then consider building a generic error handler.
这篇关于处理CloudKit错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
