Proposal for hook into resolution attempts of already resolved/rejected promise

[bmeurer]

As discussed during the summit, V8 could provide a hook to notify the embedder (Node/Chrome) about swallowed promise rejections, specifically with the Promise constructor (see Use Case #3 in promise-use-cases). I've written a design document how to extend the V8 C++ API here.

cc @MayaLekova @benjamingr

[benjamingr]

The hook sounds good to me (Confirming Node.js can do it and that it is sufficient to address the use case in question and expose a hook from Node's side).

Regarding the API - I'm not sure it should be the same function since no actual promise rejection is happening .

[bmeurer]

It'd be convenient to re-use the existing C++ API, since it exposes everything we need. But that's not a requirement, we can also introduce a new C++ API if you think that's better.

[benjamingr]

@bmeurer I think it's confusing to reuse the hook since at the moment it's only called when a promise rejects but I don't have very strong feelings about it.

Also cc @misterdjules who has raised this concern about promises before and @getify who raised this issue as well.

[bmeurer]

@benjamingr sounds reasonable. I added another possible solution which would introduce a dedicated C++ hook just for this case.

[misterdjules]

Without the ability to differentiate between programmer errors (bugs that materialize as an uncaught exception) and operational errors (reject is called with an error object), I'm not sure it's going to be possible for the embedder or a developer to determine whether the process should crash or not.

Would it be possible to add the ability to differentiate between those two different use cases?

[benjamingr]

Would it be possible to add the ability to differentiate between those two different use cases?

Unfortunately programmer errors and operational errors in the Promise constructor are not always distinguishable by whether or not it's a throw or a reject. I've seen multiple projects throw in the Promise constructor for operational stuff explicitly when doing the research for the summit.

Note that this hook is specifically for multiple throws/rejects and the current hook for promise rejections doesn't create a distinction. The line gets even blurrier in async functions (although that's not this issue).

I would love discussing how we can better distinguish programmer/operational errors and be more helpful towards programmers. (Although I think that should be a separate issue IMO).

If you think there is value in the promise rejection hook exposing whether or not a promise was thrown and not rejected for APMs or debugging then that's also worth discussing (again, I believe in a separate issue).

---

If I understand it correctly - this issue is specifically about detecting multiple rejects or throws in the promise constructor and providing a hook for that that APMs can hook into or Node.js can warn on.

[misterdjules]

Unfortunately programmer errors and operational errors in the Promise constructor are not always distinguishable by whether or not it's a throw or a reject. I've seen multiple projects throw in the Promise constructor for operational stuff explicitly when doing the research for the summit.

That's good to know. Do you have more details to share about that specific part of your research (how it was done, your findings, etc.)? I think it could be useful to include in one of the documents in this repository for future reference.

Note that this hook is specifically for multiple throws/rejects and the current hook for promise rejections doesn't create a distinction. The line gets even blurrier in async functions (although that's not this issue).

Ah you're right, I was confused by the title of the issue. Reading the design document it's now clear that this is about a very specific use case. @bmeurer Do you think renaming this issue as "Proposal for hook into already resolved/rejected promise" would help clarify this?

I agree in this case it's clear that there is a bug in the application and that developers/embedders can take appropriate action, including crashing.

I also agree that being able to differentiate between promises rejected due to programmer or operational error should be discussed in a different issue.

Thanks for the clarification @benjamingr!

[bmeurer]

@misterdjules Added "Proposal for hook into already resolved/rejected promise" as subtitle to the design document. 👍

[getify]

this issue is specifically about detecting multiple rejects or throws in the promise constructor

Is there a separate issue for catching exceptions that happened in the promise constructor without the use of throw, like calling doesNotExist()? That is absolutely an important use-case for me.

Unfortunately programmer errors and operational errors in the Promise constructor are not always distinguishable by whether or not it's a throw or a reject.

Certainly that line may be blurry. But the line that shouldn't be blurry is whether an exception came from an explicit throw or whether it came from a runtime mistake in the programming. THAT distinction is very important to me. If that's a different issue or hook, fine. But I just wanted to make sure that wasn't getting glossed over.

[mhdawson]

Is it also possible to resolve after rejecting, needing a

kPromiseResolvedAfterReject = 3

[bmeurer]

@mhdawson I guess that'd be kPromiseResolveAfterResolved. The terminology is a bit odd here, but resolved for a promise actually means that it's no longer pending.