I've read two really interesting pieces of advice, recently:
assert
over NSAssert
... is there any reason NOT to use assert
? (it's less letters :))To answer your two questions:
There should be very little performance hit for leaving in an assertion, unless the actual action in the assertion is time consuming (e.g. assert([obj calculateMeaningOfLife] == 42)
). An assertion should be no different than an extra if
statement, performance-wise. The reason for stripping out assertions in release builds is that they are essentially a debugging tool--they catch inconsistent internal program state at runtime. From a developer perspective, it's much better for an app to crash as soon as something goes wrong, but from a user perspective it's arguably less annoying if the app doesn't crash (unless letting the app run with abnormal state causes something horrible to happen), and exposing development details in error messages can be off-putting. There are good arguments on both sides--if I remember correctly, Code Complete recommends stripping them out but The Pragmatic Programmer recommends leaving them in. In any case, assertions are not a substitute for proper error handling and should only be used for programming errors.
The basic difference between an NSAssert
and a regular assert
is that an NSAssert
raises an exception when it fails while an assert
just crashes the app. NSAssert
also lets you supply fancier error messages and logs them. Practically, I really don't think there's much difference between the two--I can't think of a reason to handle an exception thrown by an assertion. (To split hairs, I think NSAssert
usually involves less typing because you don't have to include assert.h
, but that's neither here nor there.)