Audio worklet error handling

[annevk]

Closure of whatwg/html#2611 made me realize that audio worklets have no error handling yet and since they can communicate this might be useful?

The one weirdness here is that this would be the first place where the class does not inherit from EventTarget. (The other solution would be to add that to all worklets, but that would expose the global quite a bit more.)

cc @domenic

[domenic]

I think they communicate errors out via onprocessorerror.

[padenot]

Yes, this is how this is set up.

When an error happens in an AudioWorkletGlobalScope, a task is queued to fire an event on the main thread, because we don't want to do this on the real-time thread, in line with what low-latency audio API generally do.

[annevk]

How does this works if the script itself throws? As far as I can tell from https://html.spec.whatwg.org/#dom-worklet-addmodule it invokes https://html.spec.whatwg.org/#run-a-module-script which invokes https://html.spec.whatwg.org/#report-the-exception which invokes https://html.spec.whatwg.org/#report-the-error which terminates at step 8 because the target presumably doesn't implement EventTarget. How would the error end up in onprocessorerror?

[padenot]

I guess it doesn't. HTML needs a spec hook so that we can get this and do our error handling.

[karlt]

processorerror communicates errors from invocation of an AudioWorkletProcessorConstructor or of the process() method. It is dispatched on an AudioWorkletNode. It is not intended for errors during addModule(), at which point there usually is no AudioWorkletNode.

The concern of an error reporting mechanism for paintWorklet exposing paint implementation specifics doesn't extend to the "Run a module script" script execution, so perhaps a worklet-level solution could still be an option.

Perhaps an exception thrown during addModule() could somehow cause the promise to be rejected, but I don't know if or how this would extend to the first exception in a triggered microtask or to the first unhandled promise rejection.

If there is any non-determinism (e.g. Math.random()), then the same script may run differently when creating another worklet global scope, in which case exceptions could not be covered by any promise.

[annevk]

I guess if these are explicitly not to be handled, then all might be in order after all and you should feel free to close this. And then if someone wanted to get at those errors at a future point we could consider how to design something for that use case then?

[rtoy]

Teleconf: Based on the comments #2267 (comment) and #2267 (comment), we will close the event.

If this is wrong, please let us know and re-open this issue or file a new one.