Re: Uncaught exceptions thrown by Cocoa documented anywhere?
Re: Uncaught exceptions thrown by Cocoa documented anywhere?
- Subject: Re: Uncaught exceptions thrown by Cocoa documented anywhere?
- From: James Hober <email@hidden>
- Date: Wed, 13 Feb 2008 23:35:04 -0800
On Feb 13, 2008, at 4:13 PM, Jens Alfke wrote:
But the Cocoa architects basically dislike exceptions, and the Cocoa
frameworks (with a very few exceptions) raise exceptions only to
indicate *programmer errors*: passing an illegal value to a parameter,
accessing an invalid array index, calling a nonexistent method, etc.
This is fine when it bites you immediately. But what if I write:
NSString *filePath = [[NSBundle mainBundle]
pathForResource:@"MyTextFile" ofType:@"txt"];
NSURL *url = [NSURL fileURLWithPath:filePath];
Is this programmer error?
It is programmer error! But it will compile fine, run fine and never
throw an exception UNLESS I remove MyTextFile.txt from the app's
package. In that case, filePath will be nil and fileURLWithPath will
throw.
Instinctively I would check that url != nil before using it. But to
code correctly I have to check that filePath != nil or wrap the
second statement in a try block. I cannot know to do this unless I
know that fileURLWithPath can throw.
How can I know that a method like fileURLWithPath, which already can
return nil for errors, might throw an exception?
1. I can chance upon the trigger.
2. I can realize, now that you have told us, that generally a
parameter cannot be nil unless the docs say it can. (And of course,
many parameters can be nil!)
3. I can read that it throws an exception in the documentation,
assuming the documentation says so. And we began this discussion
lamenting it doesn't always.
James
_______________________________________________
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