Re: Error and Exception Handling: When to use
Re: Error and Exception Handling: When to use
- Subject: Re: Error and Exception Handling: When to use
- From: Ryan Homer <email@hidden>
- Date: Wed, 27 Jun 2007 14:57:07 -0400
Hi Nelson,
First of all, correction to my previous message in which I stated
that an unhandled exception might cause a Cocoa application to
terminate. I think you discovered that that's not true. According to
the docs "Exceptions on the main thread of a Cocoa application do not
typically rise to the level of the uncaught exception handler because
NSApplication catches all such exceptions."
Does anyone else write their programs with these things in mind or
am I thinking too deeply?
No, I don't think you are thinking too deeply. I've been going
through the same sort of thinking on my end and I think it's worth
figuring out how you should use the various methods of handling
errors, especially in a framework like Cocoa where convention seems
to play a big role in things working correctly. By that I mean that
there seems to be acceptable ways of doing certain things and things
seems to work better within the framework when these conventions are
followed.
I use asserts when I won't accept a certain error condition under any
circumstance. For example, dividing by zero is just not
mathematically acceptable so if a method accepts a parameter foo and
in that method I divide by foo, I won't accept zero at all. So, if it
fails in the release code, I want the application to crash, the error
reported and the bug fixed. Not that I really would want the
application to crash on a user - I really want it to crash in testing
- but you get the idea. In other words, the method would be totally
useless diving by foo when it is zero, so if the method continued,
we'd likely have corrupt or unpredictable data.
To put that into context, if your example had to do with setting up
an automation process to build two-door and four-door cars, I might
assert that number of doors = 2 or 4 otherwise just halt everything,
let me fix the error and try again. But if it were a modelling
application and the user were adding doors by dragging them in place,
each time a door was added, I'd test, but not assert and display
error messages as appropriate.
I'm about to re-read the documentation to decide when to use NSError
vs. exception handling now. :-)
RH
On 14-Jun-07, at 06/14/07 10:25 PM, Nelson Santos wrote:
Hi all,
Me again. Once again thanks to everyone's input on this subject.
I finally had some time to play around with exceptions and error
handling, but I still have a question. I'll use a quick example to
illustrate:
// Car.h:
#import <Cocoa/Cocoa.h>
typedef enum
{
DOORS_TWO = 2,
DOORS_FOUR = 4
} CarNumDoors;
@interface Car : NSObject
{
CarNumDoors _numDoors;
}
- (void)setNumDoors:(CarNumDoors)numDoors;
@end
// Car.m:
#import "Car.h"
@implementation Car
- (void)setNumDoors:(CarNumDoors)numDoors
{
NSAssert(numDoors >= DOORS_TWO && numDoors <= DOORS_FOUR,
@"Invalid number of car doors.");
_numDoors = numDoors;
}
@end
Calling code is this:
Car *newCar = [[Car alloc] init];
[newCar setNumDoors:8]; // Oh oh! Someone didn't call the method
properly!
When running this program with the debugger active, it's
beautiful. The debugger halts when the Assertion is raised.
Excellent. Now, let's say this code slipped through the testing
phase of the project and now sits in a release version being
distributed. I have confirmed that the assertion is still
triggered in the release version (because the instance variable is
not changed) and it appears that the current event loop is
cancelled and the program carries on, as Mr. Uli Kusterer has
said. It also appears that NSApplication catches the exception
thrown by NSAssert at the top level, since the application doesn't
close (as Ryan Homer has said.)
That all cool but it doesn't help me, the developer, know that
there is still a problem in the code. I would think the best
approach would be to inform the user that an exception was raised
and maybe click on a button to report the bug to my web site, and
then continue running. How would I go about doing that? Is there
a single logical place I should implement that? I don't want to
rely on my testing abilities to make sure that each and every
method works the way they were designed. After all, I may not be
the only one using my code and I'm sure the next guy would
appreciate knowing that there aren't little gaps in the code that
can take forever to figure out.
Does anyone else write their programs with these things in mind or
am I thinking too deeply? Does anyone else have a different idea?
Thanks.
Nelson
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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
_______________________________________________
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