Question

I come from a Java background, where try/catch is common practice.

After few months working with objective-c I have never implemented try/catch in my iOS app, because of the nature of the language itself, and general advices for not using it.

Therefore I have always tried to build error free code. But, at time of writing, I still didn’t know how a simple thing like that can be translated in objective-c:

// some operation
try {
  // do some work
} catch (SomethingWentWrongException e) {
  // log error, inform user...etc
}
// some more operation and rest of the code

With this code operation around try/catch is executed, but the program is not broke, and the rest of the code after catch is executed.

However there’s a rule telling that we shouldn’t use try catch for flow control.
I would like to implement something similar with objective-c, encapsulate some less important operations that may succeed or not, without breaking the workflow.

How can I do that without objective-c @try ?

thanks

Answer 1

You can do that with Objective-C using @try and @catch (and @finally). There’s no “rule” that says you don’t, but there is a pervasive design idiom throughout Cocoa and code build to integrate with Cocoa: exceptions are reserved for programmer error. That means if the person using your API doesn’t honour the contract, or doesn’t satisfy some preconditions for calling your methods, that is the only time that many Objective-C developers would use exceptions.

The common idiom for handling errors (e.g. my file went away, I couldn’t get the resource I needed etc) in Objective-C code is to use Cocoa’s NSError class, passing an instance by reference to the method that could possibly fail. So, rewriting your example:

// some operation
NSError *error;
BOOL itWorked = [object doSomeThingThatCouldFail: &error];
if (!itWorked) {
    // log error, inform user etc.
}
// some more operation and rest of the code

Notice that you check the return value of the method to check whether it succeeded or failed. The error object is guaranteed to be set on failure, but no promise is made about it on success.

The way the implementation of the method works with the error:

- (BOOL)doSomeThingThatCouldFail: (NSError *__autoreleasing*)error {
  //...
  if (!success && error) //check that the user actually supplied an error pointer
  {
    NSDictionary *errorDetails = @{ ... };
    *error = [NSError errorWithDomain: @"Your error domain" code: someInteger userInfo: errorDetails];
  }
  return success;
}