[ACCEPTED]-What's the point of NSAssert, actually?-nsassert

Assert is to make sure a value is what its 14 supposed to be. If an assertion fails that 13 means something went wrong and so the app 12 quits. One reason to use assert would be 11 if you have some function that will not 10 behave or will create very bad side effects 9 if one of the parameters passed to it is 8 not exactly some value (or a range of values) you 7 can put an assert to make sure that value 6 is what you expect it to be, and if it's 5 not then something is really wrong, and 4 so the app quits. Assert can be very useful 3 for debugging/unit testing, and also when 2 you provide frameworks to stop the users 1 from doing "evil" things.

I can't really speak to NSAssert, but I 16 imagine that it works similarly to C's assert().

assert() is 15 used to enforce a semantic contract in your 14 code. What does that mean, you ask?

Well, it's 13 like you said: if you have a function that 12 should never receive a -1, you can have 11 assert() enforce that:

void gimme_positive_ints(int i) {
  assert(i > 0);
}

And now you'll see 10 something like this in the error log (or 9 STDERR):

Assertion i > 0 failed: file example.c, line 2

So not only does it safe-guard against 8 potentially bad inputs but it logs them 7 in a useful, standard way.

Oh, and at least 6 in C assert() was a macro, so you could 5 redefine assert() as a no-op in your release 4 code. I don't know if that's the case with 3 NSAssert (or even assert() any more), but 2 it was pretty useful to compile out those 1 checks.

NSAssert gives you more than just crashing the app. It 15 tells you the class, method, and the line 14 where the assertion occurred. All the assertions 13 can also be easily deactivated using NS_BLOCK_ASSERTIONS. Thus 12 making it more suitable for debugging. On 11 the other hand, throwing an NSException only crashes 10 the app. It also does not tell about the 9 location of the exception, nor can it be 8 disabled so simply. See the difference in 7 the images below.

The app crashes because 6 an assertion also raises an exception, as 5 the NSAssert documentation states:

When invoked, an assertion handler 4 prints an error message that includes 3 the method and class names (or the function 2 name). It then raises an NSInternalInconsistencyException 1 exception.

NSAssert:

NSException:

Apart from what everyone said above, the 3 default behaviour of NSAssert() (unlike C’s assert()) is to 2 throw an exception, which you can catch 1 and handle. For instance, Xcode does this.

Just to clarify, as somebody mentioned but 20 not fully explained, the reason for having 19 and using asserts instead of just creating 18 custom code (doing ifs and raising an exception 17 for bad data, for instance) is that asserts 16 SHOULD be disabled for production applications.

While 15 developing and debugging, asserts are enabled 14 for you to catch errors. The program will 13 halt when an assert is evaluated as false. But, when 12 compiling for production, the compiler omits 11 the assertion code and actually MAKE YOUR 10 PROGRAM RUN FASTER. By then, hopefully, you 9 have fixed all the bugs. In case your program 8 still has bugs while in production (when 7 assertions are disabled and the program 6 "skips over" the assertions), your program 5 will probably end up crashing at some other 4 point.

From NSAssert's help: "Assertions 3 are disabled if the preprocessor macro NS_BLOCK_ASSERTIONS 2 is defined." So, just put the macro in your 1 distribution target [only].

NSAssert (and its stdlib equivalent assert) are to detect 12 programming errors during development. You 11 should never have an assertion that fails 10 in a production (released) application. So 9 you might assert that you never pass a negative 8 number to a method that requires a positive 7 argument. If the assertion ever fails during 6 testing, you have a bug. If, however, the 5 value that's passed is entered by the user, you 4 need to do proper validation of the input 3 rather than relying on the assertion in 2 production (you can set a #define for release 1 builds that disables NSAssert*.

Assertions are commonly used to enforce 8 the intended use of a particular method 7 or piece of logic. Let's say you were writing 6 a method which calculates the sum of two 5 greater than zero integers. In order to 4 make sure the method was always used as 3 intended you would probably put an assert 2 which tests that condition.

Short answer: They 1 enforce that your code is used only as intended.

It's worthwhile to point out that aside 5 from run time checking, assert programming 4 is a important facility used when you design 3 your code by contract.

More info on the subject 2 of assertion and design by contract can 1 be found below:

Assertion (software development)

Design by contract

Programming With Assertions

Design by Contract, by Example [Paperback]

To fully answer his question, the point 12 of any type of assert is to aid debugging. It 11 is more valuable to catch errors at their 10 source, then to catch them in the debugger 9 when they cause crashes.

For example, you 8 may pass a value to a function expects values 7 in a certain range. The function may store 6 the value for later use, and on later use 5 the application crashes. The call stack 4 seen in this scenario would not show the 3 source of the bad value. It's better to 2 catch the bad value as it comes in to find 1 out who's passing the bad value and why.