iPhone Versus Exceptions
I’m continuing to make slow forward progress with my DAAP-based music player for the iPhone. My most recent changes have taken this in the direction of being much more like the standard music player functionality on the iPhone. In particular, I’ve switched over to using a tab view controller for the major perspectives of viewing the music database.
Tab Based Main View
In addition, there is now a (very) rudimentary Now Playing screen to control playback.
Now Playing View
iPhone Versus Exceptions
In my last entry , I mentioned that I’ve struggled through some interesting differences when dealing with iPhone development when compared to my years of experience in Java. As a long time Java developer, I’m very accustomed to the use of checked exceptions. Most, if not all, error handling in Java is handled through the creation, throwing and catching of exceptions. I’m accustomed to catching/handling exceptions from the underlying libraries as well as creating and throwing my own exceptions. It was with that background that I approached iPhone development and quickly found out that is not the recommended way of handling error conditions. While, the standard try/catch functionality is supported in Objective-C, the documentation for Cocoa development makes it clear that using exceptions should be avoided:
Important : You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime.
Instead of exceptions, error objects (NSError) and the Cocoa error-delivery mechanism are the recommended way to communicate expected errors in Cocoa applications.
This is an important difference to understand when transitioning to Cocoa development from Java development. While this is important to understand when making calls to library methods and functions, it must also be considered when defining your own calling conventions and libraries. In order to remain consistent, it is important to use the pattern of NSError usage.