[browser][mt] Propagate unhandled JS errors in JSWebWorker to the top level Task

[lambdageek]

If user code uses setTimeout to queue work on the JSWebWorker and that code throws unhandled exceptions, we should not bring down the whole runtime in a disorganized manner.

Should we propagate unhandled JS errors the JSWebWorker top level Task ?

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

null

Author:	lambdageek
Assignees:	-
Labels:	arch-wasm, area-Threading-mono
Milestone:	-

[pavelsavara]

I guess we don't have any manifestation of this yet?

Anyway, I think that calling back from JS to C# will happen via JSExport and that propagates exceptions correctly.

Is there another concern ?

[pavelsavara]

We do subscribe to unhandledrejection and error top level events in the UI thread and shut down the runtime when that happens, when internal withExitOnUnhandledError is used.

runtime/src/mono/browser/runtime/loader/run.ts

Lines 75 to 76 in 9429e43

	globalThis.addEventListener("unhandledrejection", (event) => handler(event, event.reason));
	globalThis.addEventListener("error", (event) => handler(event, event.error));

Is that too strict ?
Should we adopt the same on the JSWebWorker too ?

[pavelsavara]

Maybe JSWebWorker should propagate unhandled JS errors from setTimeout to the JSWebWorker top level Task ?