Propagate AudioContext.decodeAudioData's error to AudioLoader.load #20301
Conversation
to AudioLoader.load
| @@ -33,6 +33,10 @@ AudioLoader.prototype = Object.assign( Object.create( Loader.prototype ), { | |||
|
|
|||
| onLoad( audioBuffer ); | |||
|
|
|||
| }, function ( error ) { | |||
|
|
|||
| throw error; | |||
There was a problem hiding this comment.
How about using onError( e ); instead?
There was a problem hiding this comment.
That would skip the LoadingManager's error handler. Does it matter?
There was a problem hiding this comment.
If you throw an exception at this point, it is not handled by the catch block in line 42. Ideally, errors in the loading process always trigger the onError() callback so the user can decide how to proceed. The loading manager could be informed about the error like so:
if ( onError ) {
onError( e );
} else {
console.error( e );
}
scope.manager.itemError( url );There was a problem hiding this comment.
Although I'm not sure LoadingManager can process the call of itemError() correctly since it would be triggered during the audio decode. At that point, itemEnd() was already called by FileLoader.
The fact that AudioLoader does a decode can actually produce a race condition in context with LoadingManager: #10706 (not sure why the issue was closed since this bug still exists).
|
Closing. Let's reconsider the error handling when #10706 is fixed. For now, you have to check if browser support the respective formats before using |
In some cases AudioContext.decodeAudioData can fail. For example, Safari doesn't support .ogg files, and decoding one triggers AudioContext.decodeAudioData's error handler. Instead of failing silently, it can be helpful to propagate this error to AudioLoader.load
reference: https://www.w3.org/TR/webaudio/#callback-decodeerrorcallback-parameters