In Objective-C/Cocoa, I'm a big fan of using the "assert" macro's to throw exceptions if something happened in programming land which is the fault of the programmer. If the assertion is not true, an exception is thrown, and the Class/Method/Line-Number is printed to the console with the exception details. This makes certain programmer errors extremely easy to track down.

For example, say you have a method that prints a string, and you "require" that all callers of the method to actually provide a string, and that it's not 0 length:

  - (void)printAString:(NSString *)aString
  {
      NSParameterAssert(aString || [aString length]);
      
      NSLog(@"Printing a string: %@", aString);
  }

If |aString| was passed as nil, or 0 length, an exception would have been thrown, showing up on the console. Class, method name, and line number, along with the exception are all printed. Super easy to find!

Asserts are also great to affirm that a method returns only "kosher" results:

  - (NSData *)loadDataFromDatabase:(NSString *)databasePath
  {
      NSData *someData = [aDataBaseClassInstance loadData:databasePath];
      
      NSAssert1(someData, @"The |databasePath| is invalid: %@", databasePath);
      
      return someData;
  }

If |someData| came back from 'aDataBaseClassInstance' as nil, an exception is thrown; the programmer provided a bad |databasePath| to the database file. The caller of -loadDataFromDatabase: never has to worry about being returned a nil NSData either. You can crash the app, do @try/@catch/@finally, or whatever you choose.

While you have to be careful where you use NSAssert()/NSParameterAssert() (Obj-C methods) and NSCAssert()/NSCParameterAssert() (C functions), it can make it easier to stay out of debugger land.