Open hoch opened 7 years ago
Currently (Chrome 66), AudioWorkletNodes
can specify an onprocessorerror
callback, which gets an Event
whenever the worklet throws.
@hoch kindly answered to my question in this issue an pointed me to this issue.
In my opinion, the most important info that error handling should extract from a worklet are those exposed by ErrorEvent
s: message
, filename
, lineno
and colno
are essential for automating logging (ie, failing worklets on the client reporting to an error handler logging onto a server) and online editing (ie, let the user edit a worklet and dynamically running it - which is what I'm trying to do).
Could I suggest to have an error handling mechanism taking into the necessity of passing these information back to the parent?
@hoch's preference would be
to expose ErrorEvent in the WorkletGlobalScope rather than AudioWorkletGlobalScope, but other folks might think otherwise.
which I believe it makes sense (all worklets exposing the same error handling mechanism), but I don't know the internals and / or the concerns regarding this approach.
Thanks!
I think unless someone can make a compelling case why having an error event without a way of communicating that error event anywhere is useful in worklets, this feature only makes sense for audio worklets and we should probably just add it there.
@hoch, my impression is that this is specified reasonably well in a Web Audio-specific way. Do you think we still need to modify the worklets spec in any way?
The issue came up from the discussion of AudioWorkletGlobalScope.
Currently WorkletGlobalScope does not have a mechanism for error handling. Has been this discussed before?