uncaughtException origin is always unhandledRejection when package.json type is module

[vladshcherbin]

Version

v16.13.1

Platform

mac os 10.14.6, Darwin uladzislaus-mbp 18.7.0 Darwin Kernel Version 18.7.0: Sun Dec 1 18:59:03 PST 2019; root:xnu-4903.278.19~1/RELEASE_X86_64 x86_64

Subsystem

No response

What steps will reproduce the bug?

1. create a script file with contents:

process.on('uncaughtException', (_, origin) => {
  console.log('whoops, uncaughtException', origin)
})

unknownFunction()

2. run node <name-of-the-file>
3. you will see whoops, uncaughtException uncaughtException
4. now, create a package.json file next to script file with contents:

{
  "type": "module"
}

5. run node <name-of-the-file>
6. now, the message will be whoops, uncaughtException unhandledRejection

How often does it reproduce? Is there a required condition?

In package.json file, type should be module to see the bug.

What is the expected behavior?

uncaughtException origin should be uncaughtException

What do you see instead?

uncaughtException origin is unhandledRejection

Additional information

No response

[aduh95]

I suppose <name-of-the-file> has a .js extension, right? Setting "type": "module" makes node parse .js files as modules (ESM) rather than classic scripts. ESM parsing is asynchronous IIRC, which I guess explains where this unhandledRejection origin comes from.
Still, there's at least one thing that is wrong in the docs:

node/doc/api/process.md

Lines 336 to 340 in 86099a3

	* `origin` {string} Indicates if the exception originates from an unhandled
	rejection or from an synchronous error. Can either be `'uncaughtException'` or
	`'unhandledRejection'`. The latter is only used in conjunction with the
	[`--unhandled-rejections`][] flag set to `strict` or `throw` and
	an unhandled rejection.

mkdir repro
cd repro
echo 'process.on("uncaughtException", (_, origin) => console.log(origin));unknownFunction()' > test.mjs
node --unhandled-rejections=none test.mjs # logs unhandleRejection, despite what the docs claim

@nodejs/modules is there a way to differentiate errors throw synchronously from unhandled rejections in an ES module? Or should we simply update the docs to document the current behavior?

[bmeck]

I see this behavior as sadly expected/unavoidable but confusing like many ESM expectations broken from transpiled forms; we should update the docs. In certain cases we can detect if the error was thrown during evaluation but in general even with that, all handling is done through Promise style handling. E.G.

let nsPromise = import('a');

• if a imports b and b throws the actual error isn't uncaught ever, it is always wrapped into a Promise when consumed via import().
• if a uses top level await we cannot know synchronously if it threw / will be handled.
• uncaughtException isn't thrown for other Promise like flows, even if using throw. E.G. prom.then(() => {throw new Error();}).

[vladshcherbin]

Yes, the file extension is .js. I was reading uncaughtExceptionMonitor docs and wanted to use its origin to distinguish uncaughtException from unhandledRejection.

Hopefully, it can be fixed for at least some cases.
I believe this should also be mentioned in the docs for other devs as origin is very confusing in the case.

[bmeck]

To be clear, I'm skeptical that we should change it without more understanding of the actual ask here. Right now the behavior of uncaughtException isn't reliable even in top level CJS contexts:

// note that this is synchronously executed:
new Promise(f => require('./file-that-throws.cjs'))

What is the exact thing we are trying to achieve rather than jumping to try and change behaviors? I see something about:

use its origin to distinguish uncaughtException from unhandledRejection.

Right now ESM never ever emits uncaughtExceptions and even we do determine when it should emit, it doesn't sound like it necessarily matches a given workflow since top level throw isn't even guaranteed to cause uncaughtException.

[aduh95]

It was discussed in the linked PR, but I think it's worth pointing it out here: the title of this issue is not quite true, you can still get 'uncaughtException' as origin in ESM as long as the exception doesn't originate from a Promise-based context, e.g.:

process.on('uncaughtException', (_, origin) => {
  console.log('whoops, uncaughtException', origin)
})

setImmediate(() => unknownFunction())

[benjamingr]

I think the whole goal of the unhandled rejection changes last year was for the behaviour of uncaughtException and unhandledRejection to be similar. It is very easy today to make an uncaughtException an unhandledRejection like Antoine and Bradley wrote.