最佳实践 - NSError域和代码为您自己的项目/应用程序 [英] Best Practice - NSError domains and codes for your own project/app

问题描述

有关设置的以前的SO帖错误域，但是为您自己的项目/应用设置错误域和自定义错误代码的最佳做法是什么？

There is a previous SO post regarding setting up error domains for your own frameworks, but what is the best practice regarding setting up error domains and custom error codes for your own project/app?

例如，假设您正在使用一个核心数据密集型应用程序，大量的验证，你应该坚持现成的核心数据错误代码（如 NSManagedObjectValidationError 从 CoreDataErrors.h ）或者你应该创建自己的 MyAppErrors.h 即 MyAppValidationErrorInvalidCombinationOfLimbs ？

For example, supposing you're working on a Core Data-intensive app with lots of validations, should you just stick with the "off the shelf" Core Data error codes (such as NSManagedObjectValidationError from CoreDataErrors.h) or should you create your own MyAppErrors.h and define errors with more specificity (i.e., MyAppValidationErrorInvalidCombinationOfLimbs?

创建自定义错误域和一组错误代码可以明显消除代码歧义，

Creating a custom error domain and set of error codes could significantly disambiguate your code, but is it too much overhead to maintain and does one have to worry about error code numbering conflicts? Or are there other concerns here?

推荐答案

NSError * myInternalError = [NSError errorWithDomain:@"com.davedelong.myproject" code:42 userInfo:someUserInfo];

域的第三部分（ @myproject）只是用于区分错误从这个项目（我的项目）从另一个项目中的错误（我的其他项目

The third part of the domain (@"myproject") is just used to differentiate the errors from this project ("My Project") from errors in another project ("My Other Project" => com.davedelong.myotherproject).

这是一种简单的方法，可以确保我不会与任何其他人的错误域（如果我使用第三方代码）冲突，除非开发商有意试图混淆只是我（我相信是不可能的...）。

It's a simple way to ensure that I'm not going to conflict with anyone else's error domains (if I'm using 3rd party code), unless that developer is purposefully trying to mess with just me (which I believe would be highly unlikely...).

对于代码编号冲突，不要担心。只要代码在域中是唯一的 ，您就可以了。

As for code numbering conflicts, don't worry about that. Just as long as codes are unique within a domain, you should be OK.

对于翻译错误，这取决于您。无论你做什么，确保你记录得很好。 个人，我通常只是传递框架生成的错误，因为他们来到我，因为我不知道我会处理所有的代码，并将所有的userInfo转换成更具体的东西我的项目。框架可以改变和添加更多的代码，或改变现有代码的意义等。它还有助于我更具体地确定错误来自哪里。例如，如果我的 StackKit 框架在 com.stackkit domain，我知道这是一个框架问题。但是，如果它在 NSURLErrorDomain 中产生错误，那么我知道它具体来自URL加载机制。

As for translating errors, that's up to you. Whatever you do, make sure you document it well. Personally, I usually just pass on framework-generated errors as they came to me, since I'm never quite sure that I'll handle all the codes and translate all of the userInfo into something more specific to my project. The frameworks could change and add more codes, or change the meaning of existing codes, etc. It also helps me more specifically identify where the error came from. For example, if my StackKit framework generates an error in the com.stackkit domain, I know that it's a framework problem. However, if it generates an error in the NSURLErrorDomain, then I know that it specifically came from the URL loading mechanism.

你可以做的是捕获框架生成的错误，并将其包装在一个新的错误对象，它有你的域和一个通用的代码，如 kFrameworkErrorCodeUnknown 或某事，然后将捕获的错误放在 NSUnderlyingErrorKey 下的 userInfo 中。 CoreData做了很多（例如，如果你尝试 save：一个 NSManagedObjectContext ，但是你有关系完整性错误，你会得到一个单一的错误，但是 NSUnderlyingErrorKey 将包含更多的信息，如具体哪些关系是错误的等）。

What you could do is capture the framework generated error and wrap it in a new error object that has your domain and a generic code, something like kFrameworkErrorCodeUnknown or something, and then place the captured error in the userInfo under the NSUnderlyingErrorKey. CoreData does this a lot (for example, if you try to save: an NSManagedObjectContext, but you have relationship integrity errors, you'll get a single error back, but the NSUnderlyingErrorKey will contain much more information, like specifically which relationships are wrong, etc).

这篇关于最佳实践 - NSError域和代码为您自己的项目/应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！