JS exceptions are hidden from developer when using Promises (async functions)

[mkonicek]

Take the following example, which (correctly) produces a redbox:

IntentAndroid.canOpenURL(url, (canOpen) => {
  // Some code that can throw ...
  throw new Error('This should redbox');
});

The Java signature is:

@ReactMethod
public void canOpenURL(String url, Callback callback)

Now change this to an async function:

@ReactMethod
public void canOpenURL(String url, Promise promise)

IntentAndroid.canOpenURL(url).then((canOpen) => {
  // Some code that can throw ...
  throw new Error('This should redbox');
});

No redbox is shown and nothing is logged which is in my opinion very poor developer experience. We've all been there - you're trying to debug a program which doesn't work but since there are no error messages and you have no idea what's wrong.

The way to "fix" this is to call done():

IntentAndroid.canOpenURL(url).then((canOpen) => {
  // Some code that can throw ...
  throw new Error('This should redbox');
}).done();  // Now throws and produces a redbox

But this is super easy to forget :(

For now, I'll go with a callback in the IntentAndroid. Feel like we need to find a good solution to this problem first before we migrate all APIs to async functions.

[davidaurelio]

• unfortunately, done() is not part of the es2015 standard
• maybe we should extend our internal promise implementation so that it produces a red box if no rejection handler is registered.

[mkonicek]

maybe we should extend our internal promise implementation so that it produces a red box if no rejection handler is registered

I like this idea a lot.

@javache, @martinbigio Do you agree?

[ide]

I like the idea too. When I thought about this before (for ObjC PromiseKit) I concluded that the promise library should check if it has an unhandled error when the promise has been deallocated (this is the only time we know that no code can add an error handler to it). So I don't think it is possible to come up with a pure JS solution that is accurate. The good news is that in RN we can likely use the native JSC API to learn when promise objects have been deallocated, but it may require some ingenuity.

[satya164]

That would be great!

[davidaurelio]

So I don't think it is possible to come up with a pure JS solution that is accurate.

Hm, I think we can do it, but maybe I’m too naive:

1. Given promise A that is rejected, we have to redbox if

   1. there is no rejection handler registered (easy to detect)

   2. any registered rejection handler throws, or returns a rejected promise, and there is no rejection handler further down the stack.

      Since .then() and .catch() return a promise A′ themselves, this is covered by case 1.i – at least one promise is eventually going to be rejected without having a registered rejection handler. These “null” promises cannot be deallocated, as the parent promise needs to keep a reference.

2. Given promise A that is resolved, we have to redbox if
   1. any resolve handler throws an error or returns a rejected promise and the corresponding child promise A′ doesn’t have a rejection handler. This is also covered by 1.i. As explained, A must keep a reference to A′, i.e. it is not garbage collected.

[ide]

A promise can be rejected and then handled later, which is why we want to learn when the programmer is done with the promise. That is, I believe (1.i) is nuanced. It's going to be really noisy if the promise library warns about potential errors that are properly handled later. False positives in such a core language feature are frustrating.

For example:

function maybeFetchDataSecurelyAsync(url) {
  if (url.startsWith('http:')) {
    return Promise.reject(new Error('only https is supported'));
  }
  return fetch(....);
}

If you call this with an http URL, the constructed promise has already been rejected but we obviously don't want to warn because someone could add a catch handler to the rejected promise later -- maybe right away, maybe a few ticks from now.

So done() is the crude way to signal that the promise isn't going to get a catch handler if it doesn't have one already, but another way would be to learn when there are no more references to the promise in the execution environment -- an approximation of this is to learn when the promise has been GC'd.

[davidaurelio]

Promise.reject() does not get rejected before the next tick, does it?
Can you think of a use case where a promise would be produced and not consumed right away?

[ide]

Can you think of a use case where a promise would be produced and not consumed right away?

Say you wanted to prefetch some data for the next screen. You might write code like this:

componentDidMount() {
  this.prefetchedDataPromise = fetch(...);
}

onNavigateToNextScreen() {
  this.prefetchedDataPromise.then(data => ..., error => {
    // fetch again or maybe just show a network error
  });
}

The cheap workaround is to add a no-op error handler:

this.prefetchedDataPromise = fetch(...);
this.prefetchedDataPromise.catch(error => {});

The downsides are that now we're back a square one and won't get an error message if the programmer forgets to add a real error handler to the promise, and this doesn't address third-party code that doesn't handle rejected promises right away. If it were possible to tell the devtools to ignore unhandled promises in specific swaths of code, the latter point wouldn't be a problem, though.

It might end up being totally fine in practice, especially if this becomes standard behavior, de facto or officially.

[davidaurelio]

I might play around with Chrome a little bit to see how it behaves (it logs unhandled rejections).

If we can create a superior solution on the native side, let’s do it. Solving it in JS just wouldn’t require us to write and maintain two solutions.

[bestander]

Can we solve the problem of missing .done() statement with linters?

[bestander]

Maybe I am dreaming here but it could be: "if promise is not returned by method than it must be .done()-d"

[bestander]

Also Firefox outputs warning if an exception is silent in a Promise, this seems to be a native feature.
Chrome team promised to do the same AFAIK