Missing flag --no-unhandled-rejections

[ivankra]

Mainline quickjs has --no-unhandled-rejections, which is useful for testing: bellard/quickjs@d20ffec

[ivankra]

For example (based on test/built-ins/Promise/any/returns-promise.js from test262):

$ ./quickjs-ng -e 'Promise.any([]);'; echo $?
Possibly unhandled promise rejection: AggregateError
1
$ ./quickjs --no-unhandled-rejection -e 'Promise.any([]);'; echo $?
0

It would be nice to have it in both qjs and run-test262 binaries.

[saghul]

We removed it and made it on by default. Ignoring unhanded rejections generally leads to bad situations. What is your use case?

Note that we removed it from the CLI, if you embed QuickJS in your own project you can choose how to implement it.

[ivankra]

Testing qjs binary against test262.

[saghul]

We already do that in this repo.Well, we already do that here, so I'm confused as to why you need the flag still.

Here is how our tracker works:

quickjs/quickjs-libc.c

Line 4762 in d17c322

void js_std_promise_rejection_tracker(JSContext *ctx, JSValueConst promise,

Then we enable it in run262 if the test requires it:

quickjs/run-test262.c

Line 1770 in d17c322

if (track_promise_rejections)

and https://github.com/search?q=repo%3Aquickjs-ng%2Fquickjs%20qjs%3Atrack-promise-rejections&type=code

Note that no test262 tests require the flag.

[ivankra]

https://github.com/tc39/test262/blob/main/test/built-ins/Promise/any/returns-promise.js is one such test that I mentioned. When run with qjs binary it would quit with exit code 1 and complain: Possibly unhandled promise rejection: AggregateError

Also, it doesn't look good to have flag differences between quickjs and quickjs-ng for no good reason.

[saghul]

https://github.com/tc39/test262/blob/main/test/built-ins/Promise/any/returns-promise.js is one such test that I mentioned. When run with qjs binary it would quit with exit code 1 and complain: Possibly unhandled promise rejection: AggregateError

We run the suite with run262, which does not set the unhandled rejection tracker, so there is no problem there. I suggest you use our runner since it does some setup to help run the suite, rather than using the vanilla qjs executable.

Also, it doesn't look good to have flag differences between quickjs and quickjs-ng for no good reason.

That is your opinion. I disagree.

[bnoordhuis]

I think the conclusion here is that we're not going to make any changes to the way things currently are. Closing.