Discussion: Conversion of NSException to NSError

[tomquist]

There are several places where FBLPromise uses Objective-C exception handling to catch NSExceptions and convert them to NSErrors. I see several problems in this approach:

1. Exceptions in Objective-C are usually used for fatal errors or programmer errors. Recovering from most exceptions results in undefined state.
2. By default Objective-C is not exception-safe when using ARC. This leads to leaked memory. There is a flag to opt in to making ARC exception-safe (-fobjc-arc-exceptions) but this has to be used for all code participating in the stack where an exception is thrown which in most cases can't be guaranteed.

What was the reasoning behind recovering from exceptions?

[shoumikhin]

I believe handling ObjC exceptions is indeed an error prone overkill, so let's get rid of that behavior.
Many thanks for raising the issue, Tom!

[shali3]

Hi @shoumikhin,
Looks like you haven't updated the docs regarding this behaviour.

[tomquist]

@shali3 The docs don't explicitly mention exceptions at all and in my opinion this is fine. The library doesn't catch exceptions anymore which is the default and expected behavior for any library in Objective C so it's not necessary to state that exceptions are not catched.

[shali3]

From the docs (link in my previous comment):

Observing rejection
To get notified when a promise is resolved with an error (i.e. is rejected), use the catch operator.

You can reject a promise in many ways:

call reject method on a promise
call reject() in an async block or return an error from the do block
return or throw an error from the then block
Or, just create a resolved promise with an error.

[tomquist]

It's talking about throwing an error, not an exception which most probably refers to Swift Errors but you're right it's confusing at least. Maybe the word "Swift" should be added.

[shali3]

From an ObjC perspective when I read error I think of NSError.