PromiseKit: Reconsider catching exceptions

Why does PromiseKit propagate exceptions (instances of the class NSException) to clients? Wouldn’t it be more appropriate to follow the Cocoa convention of using errors (instances of the class NSError) exclusively to indicate failure?

Since clients rescue from erros instead of catch exceptions, I suggest to rename -[Promise catch] to -[Promise rescue] or -[Promise error]. If clients write code that throws exceptions, it is the clients fault that should be handled during development. Error handling at runtime should not occur by catching exceptions.

The Error Handling Programming Guide - A Note on Errors and Exceptions states the following:

It is important to keep in mind the difference between error objects and exception objects in Cocoa and Cocoa Touch, and when to use one or the other in your code. They serve different purposes and should not be confused.

Exceptions (represented by NSException objects) are for programming errors, such as an array index that is out of bounds or an invalid method argument. User-level errors (represented by NSError objects) are for runtime errors, such as when a file cannot be found or a string in a certain encoding cannot be read. Conditions giving rise to exceptions are due to programming errors; you should deal with these errors before you ship a product. Runtime errors can always occur, and you should communicate these (via NSError objects) to the user in as much detail as is required.

Although exceptions should ideally be taken care of before deployment, a shipped application can still experience exceptions as a result of some truly exceptional situation such as “out of memory” or “boot volume not available.” It is best to allow the highest level of the application—the global application object itself—to deal with these situations."

Let me know what you think.