Skip to content

Add an ErrorEvent. #53

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

Closed
riju opened this issue May 11, 2020 · 3 comments
Closed

Add an ErrorEvent. #53

riju opened this issue May 11, 2020 · 3 comments

Comments

@riju
Copy link

riju commented May 11, 2020

It would be nice to add an ErrorEvent to nicely handle errors in the error EventListener. I understand with promises we can always reject Promise and throw errors that we cannot escape, but for other "minor" errors it's good to handle the onerror EventListener. It will help us to distinguish different kinds of errors, temporary vs permanent, etc.

const videoDecoder = new VideoDecoder({
  output: someCanvas
});

videoDecoder.configure({codec: 'vp8'}).then(() => {
  streamEncodedChunks(videoDecoder.decode.bind(videoDecoder));
}).catch(() => {
  // App provides fallback logic when config not supported.
  ...
});
...

videoDecoder.onerror = event => {
    console.log("Error!  ");
  };

OR 

videoDecoder.addEventListener('error', error => console.log(`Error: ${error.name}`));

Strawman proposal :

[SecureContext, Exposed=(DedicatedWorker, Window)]
interface WebcodecsErrorEvent : Event {
  constructor(DOMString type, WebcodecsErrorEventInit errorEventInitDict);
  readonly attribute DOMException error;
};

dictionary WebcodecsErrorEventInit : EventInit {
  required DOMException error;
};


interface VideoDecoder {
  ...
  attribute EventHandler onerror;
}

Somewhat related to #49

@kenchris
Copy link

You want this as a global error handler? Like will the event also fire for rejected promises? Would be good to check what the precedent is for this behavior

@dalecurtis
Copy link
Contributor

As noted in the meeting, since the rest of the API uses callbacks, I don't think we should mixin events for consistency.

@chcunningham
Copy link
Collaborator

API has changed a lot since this was filed. There are now two types of errors and they're surfaced in different ways.

Non-fatal errors are detected synchronously in response to an API call and surfaced via exception. An example would be calling configure() or decode() with inputs that are missing required parameters. The state of the codec is not altered by these errors.

Fatal errors are detected while decoding/encoding, surfaced via the error callback. Generally these are codec errors, often caused by corrupt input.

Please open new issues for feedback on this design.

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

No branches or pull requests

4 participants