有一个previous SO post关于为您自己的框架设置错误域，但是关于设置错误域和自定义错误代码的最佳实践是什么为您自己的项目/应用程序？
例如，假设您正在开发具有大量验证的核心数据密集型应用程序，您是否应该坚持使用“现成的”核心数据错误代码(例如 NSManagedObjectValidationError CoreDataErrors.h)还是应该创建自己的 MyAppErrors.h 并更具体地定义错误(即，MyAppValidationErrorInvalidCombinationOfLimbs？
创建一个自定义错误域和一组错误代码可以显着消除您的代码歧义，但是维护开销是否太大，是否需要担心错误代码编号冲突？还是这里有其他顾虑？
最佳答案
我个人使用反向 DNS 样式的域。例如:
NSError * myInternalError = [NSError errorWithDomain:@"com.davedelong.myproject" code:42 userInfo:someUserInfo];
域的第三部分(@"myproject")只是用来区分这个项目的错误("My Project")和另一个项目的错误(“我的其他项目” => com.davedelong.myotherproject)。
这是一种确保我不会与其他人的错误域冲突的简单方法(如果我使用的是第 3 方代码)，除非该开发人员故意试图弄乱只是我(我认为这不太可能......)。
至于代码编号冲突，不用担心。只要代码在域内是唯一的，就应该没问题。
至于翻译错误，这取决于您。不管你做什么，确保你把它记录好。 就个人而言，我通常只是将框架生成的错误传递给我，因为我不太确定我是否会处理所有代码并将所有 userInfo 转换为更具体的内容我的项目。框架可以更改和添加更多代码，或者更改现有代码的含义等。它还可以帮助我更具体地确定错误的来源。例如，如果我的 StackKit框架在 com.stackkit 域中生成错误，我知道这是框架问题。但是，如果它在 NSURLErrorDomain 中产生错误，那么我知道它具体来自 URL 加载机制。
您可以做的是捕获框架生成的错误并将其包装在具有您的域和通用代码的新错误对象中，例如 kFrameworkErrorCodeUnknown 或其他东西，然后将捕获的错误放在 NSUnderlyingErrorKey 下的 userInfo 中。 CoreData 经常这样做(例如，如果您尝试 save: 一个 NSManagedObjectContext，但您遇到了关系完整性错误，您将得到一个错误返回，但是NSUnderlyingErrorKey 将包含更多信息，例如具体哪些关系是错误的等)。
关于objective-c - 最佳实践 - 您自己的项目/应用程序的 NSError 域和代码，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3276127/