We are writing an API for iphone developers and we don't know what the best practice is for exception handling. We looked into NSError, standard POSIX way, NSException
What is the convention that most APIs use? Which is the most "Objective-C friendly"?
From the Introduction to Exception Programming Topics:
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. For further information, see Error Handling Programming Guide For Cocoa.
So as I understand it, only use exceptions when something is fatally wrong. Otherwise, use NSError objects.
+1 for NSError.
I forget where in the Apple docs I read this, but I also recall them encouraging the coding philosophy of "try first, then check for errors," as opposed to "check for validity, then do the operation." For example, instead of seeing if the network is available before using it, just try to use it and respond to an error if/when you get one back.
I agree with this philosophy for many use cases because (a) it moves validity-checking to the moment of action, so in a sense it's more accurate, and (b, subjective) it's more fun to work with code in this pattern.
To summarize, the suggestion is to use NSError, and to provide immediate feedback with NSError** parameters that accept NULL, to be very friendly to your API-users! This pattern is also established in several places in Cocoa/Touch; for example the NSString method writeToFile:atomically:encoding:error:.