chanson

There have been some Objective-C language enhancements in GCC 3.3 that are available to anyone working on Mac OS X Panther (10.3). Unfortunately they require support from the Objective-C runtime, so while they integrate correctly with code developed on earlier operating systems, code that uses them won't run on earlier operating systems. Hopefully these changes will also be supported soon by the GNU Objective-C runtime used by GNUstep; they seem very useful.

There are two major enhancements described in the GCC 3.3 release notes included with the August 2003 GCC update: A Java-style exception handling system, and Java-style synchronization blocks. Previous versions of Cocoa used preprocessor macros based on setjmp and longjmp for exception handling, and neither the language nor the framework had built-in thread synchronization primitives. (Cocoa did have several classes providing synchronization functionality though.)

The new exception handling system is modeled very closely on Java's. In the current system, you write code like this to handle exceptions:

  NS_DURING
  {
    ...
    [NSException raise:NSInvalidArgumentException
                format:@"Invalid argument '%@' to method 'blah'", argument];
    ...
  }
  NS_HANDLER
  {
    if ([[localException name] isEqualToString:NSInvalidArgumentException]) {
      // handle the exception
    } else {
      [localException raise]; // re-raise the exception
    }
  }
  NS_ENDHANDLER

Now, you would write the same thing as:

  @try {
    ...
    @throw [[[MyInvalidArgumentException alloc] init] autorelease];
    ...
  }
  
  @catch (MyInvalidArgumentException *invalidArgumentException) {
    // handle the exception
    
    @throw; // re-throw the exception if it wasn't handled
  }
  
  @catch (id allOtherExceptions) {
    // all other exceptions will be caught by this general construct,
    // or if it isn't used, they'll be caught higher up the call chain
    // just like in Java or C++
  }
  
  @finally {
    // do any cleanup that needs to be done regardless of whether
    // an exception was thrown
  }

This will lead to much cleaner code in the long run, and it's a much closer match to what many developers new to Cocoa and Objective-C are used to as well. Everybody wins!

The other feature added is Java-style serialization. It's not a complete implementation of Java's synchronized keyword; the only thing supported are blocks synchronized on a single object. But that's plenty because it means you no longer have to maintain your own NSLock for simple synchronization:

  NSMutableArray *sharedQueue = [[NSMutableArray alloc] initWithCapacity:5];
  
  ...
  
  @synchronized (sharedQueue) {
    // add an element to the shared queue
    [sharedQueue addObject:object];
  }
  
  ...
  
  @synchronized (sharedQueue) {
    // remove an element from the shared queue
    if ([sharedQueue count] > 0) {
      element = [sharedQueue removeObjectAtIndex:0];
    }
  }

See? Much more straightforward than managing a separate NSLock. (Of course, for shared work queues you're generally better off using an NSConditionLock but this is just an illustration...)

Hopefully Objective-C will continue to evolve and do so in the right direction. There are some interesting discussions taking place now about the language's future in various places like the GNUstep discussion list and the comp.lang.objective-c Usenet newsgroup.