When porting Java code to ObjC, how best to represent checked exceptions?

Question

I am working on porting a Java codebase to Cocoa/Objective-C for use on desktop Mac OS X. The Java code has lots and lots of methods with checked exceptions li

Answer 1

You should definitely avoid exceptions for things like parsing numbers from strings. In Objective-C, exceptions represent programmer error, not user input error, or even unavailable files. (Part of the reason is that exception handling is always more costly and complex than more "conventional" error handling. Regardless of the fact that entering @try blocks is "zero cost" in 64-bit, it's still slow whenever an exception is actually raised.) Of course, you're allowed to use exceptions as you like, but it's not the Cocoa way, and you'll find yourself at odds with other Objective-C code. People who use your code will be incredibly annoyed that you throw exceptions in cases that should just result in an error.

From Apple's own docs:

"In many environments, use of exceptions is fairly commonplace. For example, you might throw an exception to signal that a routine could not execute normally—such as when a file is missing or data could not be parsed correctly. Exceptions are resource-intensive in Objective-C. You should not use exceptions for general flow-control, or simply to signify errors. Instead you should use the return value of a method or function to indicate that an error has occurred, and provide information about the problem in an error object."

Look at how built-in Cocoa classes handle errors like this. For example, NSString has methods like -floatValue that return 0 if it fails. A better solution for your particular situation might be how NSScanner does it, such as in -scanFloat: — accept a pointer to the field where the result should be stored, and return YES or NO based on whether the parse was successful.

Aside from Obejctive-C convention and best practices, NSError is much more robust and flexibly than NSException, and allows the caller to effectively ignore the problem if they want to. I suggest reading through the Error Handling Programming Guide For Cocoa. Note: If you accept an NSError** param, I strongly suggest you also design to allow the client to pass NULL if they don't want to receive any error information. Every Cocoa class I'm aware of does this for errors, including NSString.

Although the ported code may end up looking totally different from the Java code, recognize that it will be used by Objective-C code, not the same clients of the Java equivalent. Definitely match the idioms of the language. The port will not be a mirror image of the Java code, but it will be much more correct (for Objective-C) as a result.