The core attributes of an NSError object—or, simply, an error object—are an error domain, a domain-specific error code, and a “user info” dictionary containing objects related to the error, most significantly description and recovery strings.
The core attributes of an NSError object are an error domain (represented by a string), a domain-specific error code and a user info dictionary containing application specific information.
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).
I don't have enough rep to comment, but for the accepted answer by Dave DeLong, it might be slightly better to use [[NSBundle mainBundle] bundleIdentifier]
instead of @"com.myName.myProject"
. This way, if you change your name or project's name, it will be reflected accurately.
How to create a custom NSError:
First create a Dictionary of the error message
NSDictionary *userInfo = @{
NSLocalizedDescriptionKey: NSLocalizedString(@"Unknown Error - Please try again", nil),
NSLocalizedFailureReasonErrorKey: NSLocalizedString(@"Unknown Error - Please try again", nil),
NSLocalizedRecoverySuggestionErrorKey: NSLocalizedString(@"Unknown Error - Please try again", nil)
};
NSError *error = [NSError errorWithDomain:[[NSBundle mainBundle] bundleIdentifier]
code:-58 userInfo:userInfo];
Then assign the userInfo to the NSDictionary and your done.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With