Best Practice - NSError domains and codes for your own project/app

Question

Hi all,

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?

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?

Thanks

Answer 1

I personally use a reverse-DNS style domain. For example:

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

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.

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.

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).