Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of exceptions in audio worklet is not very clear #1984

Closed
bzbarsky opened this issue Jul 7, 2019 · 11 comments · Fixed by #2003
Closed

Handling of exceptions in audio worklet is not very clear #1984

bzbarsky opened this issue Jul 7, 2019 · 11 comments · Fixed by #2003
Assignees

Comments

@bzbarsky
Copy link

bzbarsky commented Jul 7, 2019

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
Copy link
Member

padenot commented Jul 11, 2019

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
Copy link
Member

hoch commented Jul 11, 2019

Or for an error during the AudioWorkletProcessor construction.

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

@hoch
Copy link
Member

hoch commented Jul 11, 2019

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
Copy link
Author

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
Copy link
Contributor

karlt commented Jul 12, 2019

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
Copy link
Author

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
Copy link
Author

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

@hoch
Copy link
Member

hoch commented Jul 17, 2019

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
Copy link
Author

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
Copy link
Member

hoch commented Jul 17, 2019

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
Copy link
Author

The plan sounds pretty reasonable to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants