[worklets] There is no way to catch "throw" or "unhandledrejection"

[samad-aghaei]

It seems that we can not handle throw(s) happened in worklets.

//index.html
window.onerror = function(event){...}
window.onunhandledrejection = function(event){...}
window.onrejectionhandled = function(event){...}

( async () => {
    //Are Worklets something between incompleted-Worker and incompleted-Dynamic-Module? :-)
    await CSS.paintWorklet.addModule("./module.js")
})()
.catch(console.log)


//module.js
throw 'myError'
/** SyntaxError is catchable by our async function. eg: break ...

....
//Uncaught myError       index.html:1
                                   ^^^^ 

As far as I know, worklets are kind of workers, if so, having [onerror, onmessage, postmessage, terminate] methods are expected and should behave asynchronously.

If they are more like dynamic module, we should have the ability of catching unhandled promise rejections.

Otherwise, can we call a Worklet a synchronous sandboxed "Realm" which they are living in main thread? If yes, still we need to catch all of its errors.

[tabatkins]

Worklets aren't Workers; they share a similar API surface and are conceptually close, but are quite different things in impl. You can't (currently) post messages to them, for instance.

Whether they live on the main thread or not is an impl detail; how many worklets live in a single global realm is also an impl detail. This is very different from Workers, which have unique Realms. So, we can't reasonably register a single global error/rejection handler, as the error/rejection could come from any of the unpredictable set of the other worklets currently sharing a global with you.

Potentially each individual Worklet registration could take such handlers, but I'm not sure what the impl costs would be.

[samad-aghaei]

Great.
If Worklets as a shared Realm context are living in main thread, It shouldn't be that difficult to pass an off canvas reference to it.

[tabatkins]

I didn't say they live on the main thread; I said it's undefined what thread they live on.

I'm not sure what the rest of your post is about, it seems to be a completely different topic from the OP. Can you bring it up in a different issue and elaborate more with examples or use-cases?

[samad-aghaei]

Do you mean that a paintWorklet thread is unknown?
Is that because of the different architecture of the browsers? would you please explain it a little more.

-P.S
I will open a new issue to explain the offScreenCanvas use-case.

[tabatkins]

Yes. In the introduction the spec explains that worklets:

Are thread-agnostic. That is, they are not defined to run on a particular thread. Rendering engines may run them wherever they choose.

They might be run in the main thread, or on a unique process per worklet, or on a small number of dedicated processes with the worklets allocated from a pool. Which is used depends on the architecture of the browser, the design of the particular worklet (AudioWorklet has different concerns than PaintWorklet, for example), and the perf/security tradeoff each browser wants to take on.

[domenic]

I think this issue is probably best closed, as it's gone in several different directions and hasn't seen much followup. It could be reopened on https://github.com/whatwg/html/issues if the OP still has concerns.