RE: Professional Error Handling
RE: Professional Error Handling
- Subject: RE: Professional Error Handling
- From: Squ Aire <email@hidden>
- Date: Fri, 23 Oct 2009 14:03:18 +0000
- Importance: Normal
Thanks, I like your idea. If I understood your correctly, the code in your example is for the files ExpressionProcessor.h and ExpressionProcessor.m.
If that is the case, why not just put it all in the .m file? And do "static" instead of "extern" on the error domain string. That way you have a local error stuff for each class. Sounds pretty reasonable to me. I think that is what I'll do unless you have some objections. Thanks for the idea!
I'm not much for the second suggestion of putting all the errors in one big header file (thanks for the idea nonetheless!). I like the idea of seperating it like you have, only that I'm not sure what purpose it serves to make it available to all other classes through a header file. At least not in my app. Maybe your app needs it to be public.
> Regarding your second case specifically, I usually define an error domain and error codes using an extern NSString* const plus an enum on a per-class basis.
>
> // This for the header
> extern NSString *const ExpressionProcessorErrorDomain;
> enum {
> EPUnmatchedParenthesesError = 21,
> EPRadixPointOnlyError = 22,
> EPSuccessiveOperatorsError = 23,
> EPSuccessiveRadixPointsError = 24,
> EPSuccessiveNegativeSignsError = 25,
> EPOperatorAtExpressionStartError = 26,
> EPOperatorAtExpressionEndError = 27,
> EPInvalidExponentialError = 28,
> EPInvalidPowerOfUnitError = 29,
> EPInvalidPlaceholderIndexError = 30,
> EPInvalidPlaceholderObjectError = 31
> };
>
> // And adding, of course, the value of ExpressionProcessorErrorDomain in the .m file
> NSString *const ExpressionProcessorErrorDomain = @"ExpressionProcessorErrorDomain";
>
> I'm not sure whether this is a Cocoa convention or not, or whether a convention exists, but this is what I use to ensure that my domains are consistent and that error codes are self-documenting (at least in the code) as well as ensuring that error code duplication doesn't occur.
>
> - Bryan
>
> On Oct 22, 2009, at 7:40:46 PM, Squ Aire wrote:
>
> 2) The error is originated in my own code. This case I'm unsure of. The way I do it currently is something like this:
> NSString *desc = @"Unable to set up image view.";
> NSString *info = @"Image does not exist at the specified path.";
> NSDictionary *d = [NSDictionary dictionaryWithObjectsAndKeys:
> desc,NSLocalizedDescriptionKey,
> info,NSLocalizedFailureReasonErrorKey,nil];
> *anError = [NSError errorWithDomain:@"com.mycompany.GreatApp.ErrorDomain" code:43 userInfo:d];
>
> And then of course return NO or nil from the method. Is this how the professionals would do it? The first, and only obvious, problem I can see with this is that I'm putting a magic number 43 in there. I determine this magic number by doing a manual project find for "GreatApp.ErrorDomain" and adding one to the greatest error number that already exists. The second problem is of the error domain string. To me it currently feels like good enough to just have one error domain for the whole app since the app is not huge. The only question is where on earth I would put a constant for that string. I have no idea, since this string can occur in various model objects, so I just manually copy-paste this string every time it's needed.
>
_________________________________________________________________
Windows Live: Make it easier for your friends to see what you’re up to on Facebook.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_2:092009_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden