testharness.js: allow_uncaught_exception in Deno - #33657

This seems reasonable to me. @zcorpan might also have an opinion.

Can you push to a trigger branch e.g. triggers/firefox_nightly and.or triggers/chrome_dev so we can get a full run and compare the results on wpt.fyi in case of unexpected side effects.

@jgraham Chrome and FF look fine. Safari is still running.

https://wpt.fyi/results/?run_id=5723359412224000&run_id=5100404940472320&run_id=5684464188391424&run_id=6225992455553024

Unfortunately found some tests that break (the ones checking that this error is not preventDefaulted) by default:

https://wpt.fyi/results/html/webappapis/scripting/events/event-handler-processing-algorithm-error?q=html%2Fwebappapis%2Fscripting%2Fevents%2F&run_id=5725982026629120&run_id=5660602692272128&run_id=6220139287543808&run_id=5727260584706048&run_id=5751907925622784&run_id=5168832627867648

Going to have to figure out how to work around this.

This looks ok to me, except for tests that test the observable differences as you found. You could add an opt out in setup() e.g.

setup({do_not_prevent_default_for_unhandled_exceptions: true});

Naming open for bikeshedding.

But such tests would still not be able to run in Deno as-is, unless you make the non-0 status code the expected result for those tests or add some opt in to allow unhandled exceptions in Deno.

Hmm, so at risk of being really bikesheddy, we are now using uncaught and unhandled in property names to mean roughly the same things. It's also a really long name. I wonder if it should be called preventDefault_uncaught_exception and default to true? But now this is adding API surface it feels like maybe it should have had an RFC.

Wouldn't the best fix here be for Deno to have some web-like mode where non-preventDefault()ed exceptions don't crash the process, and then use that when running these tests (or perhaps all web platform tests)?

@domenic Yeah that could work too. I'll look into that.