Promise constructor error swallowing use case

[benjamingr]

Use case around a problem with this behavior that people ran into (maybe take off SO question):

new Promise((resolve, reject) => {
  resolve(3);
  throw new Error();
});

[benjamingr]

Resolved with https://github.com/nodejs/promise-use-cases/blob/master/use-cases/warnings/3/3.md thanks @MadaraUchiha

[getify]

That use-case doc is fine, but I don't think it fully captures all sides of this issue. It focuses mostly on if the user calls resolve(..) after reject(..) or vice versa.

But more specifically, I think the biggest "trap" is the unexpected exception (not explicit reject(..)) that may occur after resolve(..) was called. Unexpected (invalid) multiple calls to an API is one type of mistake, but properly using the API (only calling resolve(..) once) and then subsequently having some other error/exception, that's a different kind of mistake.

That use-case is different because I would argue the end-user's expectation was violated differently and thus the "solution" would need to be different.

IOW, I don't need a warning in that case, what I actually need is that my promise is actually rejected, the same way as if the unexpected exception had occurred first.

BetterPromise does this, specifically... it traps for any uncaught exceptions (not rejections) that occur after a resolve(..) or reject(..) was explicitly called, and if so, that exception overrides the promise resolution to be a rejection.

[benjamingr]

Would you mind adding a use-case you believe captures this violation of expectation?

It would be great to suggest shipping an async_hook that would allow interception of throws and log them to APM tools or terminate the process.

[getify]

Done. :)