{"id":174,"date":"2008-12-04T06:03:39","date_gmt":"2008-12-04T11:03:39","guid":{"rendered":"http:\/\/vgable.com\/blog\/2008\/12\/04\/nsassert-considered-harmful\/"},"modified":"2009-06-01T14:14:08","modified_gmt":"2009-06-01T19:14:08","slug":"nsassert-considered-harmful","status":"publish","type":"post","link":"https:\/\/vgable.com\/blog\/2008\/12\/04\/nsassert-considered-harmful\/","title":{"rendered":"NSAssert Considered Harmful"},"content":{"rendered":"

The NSAssert()<\/a><\/code> function is unreliable, and therefore dangerous. Plain-old assert()<\/a><\/code> is a better choice.<\/strong><\/p>\n

Note that #define NDEBUG<\/code> disables assert()<\/code>; and #define NS_BLOCK_ASSERTIONS<\/code> disables NSAssert()<\/code>. One kind of assert being disabled does not mean the other kind is. Nether kind of assertion is disabled by default when building in “Release” mode — you must be sure to disable them yourself. Be careful, a user will not appreciate the difference between a bug and a failed assertion — both are a crash. <\/p>\n

assert()<\/code> immediately<\/em> stops your program with a SIGABORT<\/code> signal. You can’t miss a failed assert()<\/code>, its behavior is predictable, and it fails fast (link is a PDF)<\/a>.<\/p>\n

But a failed NSAssert()<\/code> behaves unpredictably. Sometimes it stops program execution, sometimes it does not and leaves the program in a strange inconsistent state. I have entirely missed NSAssert()<\/code>s failing, because I did not look at the console. if(!expr) NSLog();<\/code> would have been a better choice in the those cases, because at least I would have known how it behaved.<\/p>\n

According to Apple<\/a>,<\/p>\n

Assertion macros, such as NSAssert and NSCAssert … pass a string to an NSAssertionHandler<\/code> object describing the failure. Each thread has its own NSAssertionHandler<\/code> object. When invoked, an assertion handler prints an error message that includes the method and class (or function) containing the assertion and raises an NSInternalInconsistencyException<\/code>.<\/p><\/blockquote>\n

Complicated! The complexity means it is possible to customize what happens when an NSAssert()<\/code> fails<\/a>. That sounds cool, but I’ve never heard of someone needing to actually do<\/em> that. <\/p>\n

If a framework catches NSInternalInconsistencyException<\/code>s, then your program will keep right on running after a failed NSAssert()<\/code>. I have had this happen to me several times. I apologize for not having taken the time to investigate what frameworks were catching what.<\/p>\n

Apple could change what catches what with any software update.<\/p>\n

Variability and complexity are the last things you want while debugging. There’s no reason to invite it them by using NSAssert()<\/code> over assert()<\/code>. Since NSAssert()<\/code> is not<\/em> guaranteed to stop your program, it can not be relied on to guard against data corruption, or anything worse then a predictable crash.<\/a><\/p>\n

UPDATE 2009-06-01: You can annotate assert()<\/code>, so it prints an explanation like NSAssert()<\/code>, by &&<\/code>ing in a string after the condition. For example assert(i < j)<\/code> is a lot<\/em> more useful with an explanation: assert(i < j && \"unexpected cycle in graph\")<\/code> — on failure it prints <\/p>\n

Assertion failed: (i < j && “unexpected cycle in graph”), function WillHalt(), file \/path\/to\/code.m, line 30.\n<\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"

The NSAssert() function is unreliable, and therefore dangerous. Plain-old assert() is a better choice. Note that #define NDEBUG disables assert(); and #define NS_BLOCK_ASSERTIONS disables NSAssert(). One kind of assert being disabled does not mean the other kind is. Nether kind of assertion is disabled by default when building in “Release” mode — you must be […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18,6,3,5,4,10],"tags":[246,77,244,245,367],"class_list":["post-174","post","type-post","status-publish","format-standard","hentry","category-bug-bite","category-cocoa","category-macosx","category-objective-c","category-programming","category-tips","tag-assert","tag-debugging","tag-nsassert","tag-nscassert","tag-testing"],"_links":{"self":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/174","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/comments?post=174"}],"version-history":[{"count":0,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/posts\/174\/revisions"}],"wp:attachment":[{"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/media?parent=174"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/categories?post=174"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vgable.com\/blog\/wp-json\/wp\/v2\/tags?post=174"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}