Question

I read Apple’s recommendation on exception usage and NSError usage:

Also, I read several similar stack overflow questions which discuss whether to use or not exception.

Exception Handeling in iOS

Using exceptions in Objective-C

Objective-C Exceptions

I am trying to figure out pros and cons of usage exception as error notification/handling method in iOS (Frankly, I am no satisfied with Apple’s sentence (it says what to do, but it doesn’t say why we should do it):

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.

Exception usage pros:

• It doesn’t require to modify all intermediate code between error generating code and error handling code

• It doesn’t pollute arguments and return values for methods

Cons:

• For all manually managed memory code we will have to be extra careful (we will need to wrap it in autoreleasing objects to make sure that resources are released).

• We need to be careful with the border between our code and framework. If our exceptions leave our code, we could be in trouble (because frameworks may manually manage memory)

Did I miss anything? Are there additional cons/pros?

It looks like exceptions should be fine for library like code (when we have quite big amount of tightly packaged code, which doesn’t communicate a lot with external systems/frameworks. And it looks like exception are hard to use for the code which actively interacts with other frameworks.

Does your experience prove this theory?

I appreciate any additional info on this subject.

Answer 1

tl;dr Exceptions should be used for fatal/non-recoverable/programmer error(s) only. Attempting to use them a la Java or other exceptions-are-recoverable environments will result in code that is more fragile, harder to maintain, and difficult to refactor while also limiting your ability to leverage system frameworks.

---

Con: If you use exceptions for flow control and/or recoverable errors in your code, your code will be, by design, different from Apple’s design patterns.

End result?

• You can’t use Apple’s APIs at all in your code unless the border between your code and Apple’s always isolates the exception behavior

• Every time your refactor, you’ll have to refactor a mass of exception handling code

• Many things that should be trivial will be very complex; for example, you won’t be able to put your objects into an enumerable collection and enumerate them without that enumeration — block, for loop, whatever… — also having exception processing at the boundaries.

Consider:

 NSArray *a = @[yourExceptionfulInstance, yourExceptionfulInstance, yourExceptionfulInstance];

@try {
    for(id k in a) { [k doSomething]; }
} @catch(...) {
}

If doSomething might raise, for any reason, the above is violation of the documented design patterns of the framework because you’ll be throwing an exception across frames within Apple’s framework(s).

That is one mighty big con. Big enough that I can’t imagine a set of pros to outweigh it.