• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Proper way to throw an exception in an iOS application...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proper way to throw an exception in an iOS application...


  • Subject: Re: Proper way to throw an exception in an iOS application...
  • From: Fritz Anderson <email@hidden>
  • Date: Sun, 18 Mar 2012 11:58:40 -0500

On 17 Mar 2012, at 4:43 PM, Quincey Morris wrote:

On Mar 17, 2012, at 14:13 , Brian Lambert wrote:

NSAssert sounds perfect for this.

On Sat, Mar 17, 2012 at 1:41 PM, Fritz Anderson <email@hidden> wrote:

[…] 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.

I'm not sure what Fritz was saying, but there's no need to provide a return statement after a NSAssert (at least, not with clang, and I don't recall needing it in GCC either).

Perhaps I was missing some subtlety (though my skimming of NSException.h seems to bear me out), but my thinking is that #defining NS_BLOCK_ASSERTIONS gives NSAssert() no effect:  

#if !defined(NS_BLOCK_ASSERTIONS)
...
#else // NS_BLOCK_ASSERTIONS defined

#if !defined(_NSAssertBody)
#define NSAssert(condition, desc, ...) do {} while (0)
#endif
...
#endif

… so if your code relies on Clang understanding that the function will exit early upon the failure of the assertion, your reliance would be misplaced. Nothing would remain to tell it so. To silence Clang, you have to provide a code path that returns as the function declaration promises.

You make the excellent point that maybe code shouldn't get into that position — you should leave the assertions in, or otherwise test and handle the exceptional condition in every case. "Assertions encapsulate the fail branch" was an incredibly awkward way to put it, though.

— 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

References: 
 >Proper way to throw an exception in an iOS application... (From: Brian Lambert <email@hidden>)
 >Re: Proper way to throw an exception in an iOS application... (From: Fritz Anderson <email@hidden>)
 >Re: Proper way to throw an exception in an iOS application... (From: Brian Lambert <email@hidden>)
 >Re: Proper way to throw an exception in an iOS application... (From: Quincey Morris <email@hidden>)

  • Prev by Date: Newbie
  • Next by Date: Brace Insertion Tweak
  • Previous by thread: Re: Proper way to throw an exception in an iOS application...
  • Next by thread: Turning off double-click to select brackets?
  • Index(es):
    • Date
    • Thread