why using 'assert' in a project? (and why using it so many times)

Question

i was reading through the sample code ListAdder, and there are many asserts right after the variable, or used in almost every method, for example :

self.formatter = [[[NSNumberFormatter alloc] init] autorelease]; assert(self.formatter != nil);

or :

- (UITableViewCell *)tableView:(UITableView *)tv cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
   #pragma unused(tv)
   #pragma unused(indexPath)
   UITableViewCell *    cell;

   assert(tv == self.tableView);
   assert(indexPath != NULL);
   assert(indexPath.section < kListAdderSectionIndexCount);
   assert(indexPath.row < ((indexPath.section == kListAdderSectionIndexNumbers) ? [self.numbers count] : 1));

I was wondering, what's the point to do that?

Thanks

Answer 1

It is an implementation of Design by Contract, or DbC.

Objective C has no native support for the pre-conditions, post-conditions and invariants of DbC, but especially post- and preconditions can be implemented pretty well with macros.

Here are some other approaches to implement DbC in Objective C:

• http://www.roard.com/contracts/
• http://lists.apple.com/archives/objc-language/2006/Sep/msg00000.html
• The D programming language has DbC, and here is Michel Fortins attempt at the same style of DbC, but for Objective C: http://michelf.com/weblog/2010/dobjc-preliminary-design/

Answer 2

The point of assertions is to make sure that bugs show up immediately, and in easily diagnosable ways, instead of as subtle misbehavior later on. In this case, the developer of that code wants to guarantee that 4 conditions hold after their code runs.

Answer 3

The asserts check the programmer's assumptions about how the code will be invoked. If the assumptions are wrong, the assert will fail and throw an exception. This makes code fail as early as possible.

Whether to do this or not is a point of debate. It can be taken too far.