Re: Proper way to throw an exception in an iOS application...
Re: Proper way to throw an exception in an iOS application...
- Subject: Re: Proper way to throw an exception in an iOS application...
- From: Brian Lambert <email@hidden>
- Date: Sat, 17 Mar 2012 14:13:48 -0700
Yes. I only use exceptions to indicate a logic error (bug) in my code.
For example, in my current work, it is a logic error to to ask for a page index that is out of range. This can only happen if I have a bug elsewhere. In debug builds, I check for this condition and throw an exception for it. In release builds, I do something reasonable so the program doesn't crash (like display the last page, vs. crashing).
I wasn't opening the can of worms about when to use exceptions, I feel comfortable that I know how to do this. I was asking about the best practice for actually throwing them.
NSAssert sounds perfect for this.
Best,
Brian
On Sat, Mar 17, 2012 at 1:41 PM, Fritz Anderson
<email@hidden> wrote:
On 17 Mar 2012, at 3:19 PM, Brian Lambert wrote:
> One camp says to use:
> [NSException raise:NSInvalidArgumentException format:@"pageIndex is out of range"];
>
> Which I was first exposed to and have been using.
>
> This doesn't seem to be ideal, though, because the compiler doesn't recognize that this represents a throw and sometimes you wind up with the awkward: "Control may reach end of non-void function" case and have to code something like:
>
> [NSException raise:NSInternalInconsistencyException format:@"Mumblefart can't be somethingorothered"];
> return nil; // Can't actually get here. Awkward Code...
>
> It would seem, then, that using @throw would be superior:
>
> @throw [NSException exceptionWithName:NSInvalidArgumentException reason:@"pageIndex is out of range" userInfo:nil];
>
> But it doesn't seem to be highly used in code I'm reading.
> I'm leaning towards switching to @throw.
>
> How do the awesomest engineers do this? Your thoughts?
That being the case, I almost always use the NSAssert() and NSParameterAssert() macros. They cover exactly the cases you show here, they do the testing without a visible if () block, and they become no-ops when you define NS_BLOCK_ASSERTIONS in your release build. Because assertions encapsulate the fail branch, you'd have to provide a return value. I wouldn't lose sleep over it.
— F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden