Handling of exceptions in audio worklet is not very clear

[bzbarsky]

https://webaudio.github.io/web-audio-api/#dom-audioworkletnode-onprocessorerror says:

When an exception is thrown from the processor’s constructor, process method, or any user-defined class method, the processor will queue a task on the control thread to fire onprocessorerror event to the node. Note that once an exception is thrown, the processor will output silence throughout its lifetime.

First, I assume it means that an event of type "processorerror" is fired, even though that's not what it says, right?

Second, is this event just an Event or does it implement some other event interface? Is there a reason to not make this an ErrorEvent, and name the attribute "onerror"?

[padenot]

I think we wanted to make it clear to authors that this was an error caused in the audio rendering thread (In the AudioWorkletGlobalScope): an error in the DSP code.

[hoch]

Or for an error during the AudioWorkletProcessor construction.

Like I mentioned, we need to expose ErrorEvent to AudioWorkletGlobalScope.

[hoch]

Related:
#1846
#1282

This is a known issue without a clear solution. I still believe this should be a part of the Worklet infra. Cross-thread posting an error to AudioWorkletNode is more of a bonus.

[bzbarsky]

To be clear, this bug is about the fact that the actual event that gets fired is not clearly defined.

There's a separate problem, handled by other issues, that what causes the event to get fired is not clearly defined at the places where that causation would occur...

[karlt]

Like I mentioned, we need to expose ErrorEvent to AudioWorkletGlobalScope.

I assume the previous mention was in response to the similar ErrorEvent question asked at #1282 (comment).

onprocessorerror is in Window scope and so an ErrorEvent would be fired in Window scope.
Wouldn't it be possible to create an ErrorEvent in Window scope instead of creating in AudioWorkletGlobalScope in order to be serialized/copied to be fired in Window scope?

The inability to clone errors for ErrorEvent.error may still make things a bit tricky.
I don't know the best way to deal with that.

[bzbarsky]

The inability to clone errors

Fixed in specs; see whatwg/html#4268

Implementation support is unclear so far, but presumably will be added at some point.

[bzbarsky]

Also, you can fire an ErrorEvent with a null .error but still a useful .message.

[hoch]

onprocessorerror is in Window scope and so an ErrorEvent would be fired in Window scope.
Wouldn't it be possible to create an ErrorEvent in Window scope instead of creating in AudioWorkletGlobalScope in order to be serialized/copied to be fired in Window scope?

I find it weird that firing an ErrorEvent on the main global scope when the actual error happens in the WorkletGlobalScope. From the main thread view point, something bad happened in the audio thread so it just needs a warning or a notification, not a world-stopping exception.

[bzbarsky]

Firing an ErrorEvent is not a world-stopping exception.

Also, we're not talking about firing an ErrorEvent on the global in the Window scope. We're talking about firing it on the AudioNode, no? This is exactly "a warning or notification", similar to the way Worker notifies the main thread about exceptions in the worker...

[hoch]

Thanks for the input. Here's my plan:
When an AudioWorkletProcessor constructor or its process() method throws, the processor will queue a task to create and fire an ErrorEvent the main control thread (global window) with the relevant information.

It's still problematic that WorkletGlobalScope doesn't have an error handling channel. The above discussion only applies to the node-processor level error handling.

[bzbarsky]

The plan sounds pretty reasonable to me.