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).
Also, it's easy enough to use NSAssert's source code (Command-click on a use of it to go to the header file that defines it) as a model for your own version of the macro that doesn't need a test condition. I think that looks cleaner in cases where you've already tested for the error with an 'if', rather than writing 'NSAssert (NO, @…")' -- and I can never quite get used to reversing the test to use as the first parameter directly.
I have to admit, I happen to prefer to leave the asserts enabled in release builds. If the exceptional condition should arise, and it's one of those hard-to-reproduce things, the message in a customer's Console log is often the only clue to what really happened.
The downside, of course, is that such exceptions will typically be caught and ignored by the frameworks, which means that the app will misbehave -- though if the condition arises, it's probably going to misbehave anyway. Also, customers are not aware of the existence of the messages until you have them go look.
I also have to admit that at one point I tried -- and distinctly failed -- to force the (released) app to terminate on any uncaught-by-my-code exception. I never figured out what I was doing wrong, but I expect I'll learn someday.