On Aug 27, 2009, at 10:27 PM, Joar Wingfors <j...@joar.com> wrote:
Terminology aside, I think that he accurately describes how the Cocoa provided assertion macros are implemented and used in general. These macros allow the developer to describe things that always must be true, and ensures that a failure prevents execution from continuing beyond that point. Used like this, the biggest upshot of turning them off is saving a few CPU cycles, but you will at the same time expose the end user to undefined state and behavior of your application and rob yourself of well defined failure points that assists in troubleshooting.
As I said before, I think that using assertions this way makes you use them less.
If assertions crash your released program, you will only want to assert when you're about to do something bad like corrupt the user's data. If you can accurately predict that, then why bother with the assert at all? But since assertions exist because no programmer is perfect at determining when an error will occur, you'll wind up missing some bad case.
For reference, the UNIX assert() calls abort() at the end.
If you have NDEBUG defined (Traditional UNIX release flag) the assert is a no-op. :)
--Kyle Sluder
_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
