W3C home > Mailing lists > Public > public-media-capture@w3.org > April 2016

[mediacapture-record] Error member in an Event for runtime-errors is a bad idea

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Wed, 13 Apr 2016 16:19:34 +0000
To: public-media-capture@w3.org
Message-ID: <issues.opened-148111977-1460564373-sysbot+gh@w3.org>
jan-ivar has just created a new issue for 

== Error member in an Event for runtime-errors is a bad idea ==
...because the `Error`'s file, line number and stack will always be 

Not only is this wasteful, it fools people into thinking it *might* 
have useful information that they better log or forward, taking the 
place of more useful information.

Here's an [example](https://jsfiddle.net/tmwLxjLy/) (yes I like 
promises, and yes the example is mediaRecorder,  but it has the same 

var rec = new MediaRecorder(stream);
var stopped = new Promise((resolve, reject) => {
  rec.onstop = resolve;
  rec.onerror = event => reject(event.error));
`stopped` resolves when the recording ends, or rejects at the first 
runtime error, whichever happens first.

But when a `SecurityError` error later shows up in my console, there's
 no file or line number. In a larger program, this would suck.

If we replace `.error` with `.name` and `.message` then I know there's
 no deeper information to forward:

    rec.onerror = event => reject(new DOMException(event.message, 

And now the `SecurityError` points to this call site, which tells me 
it's a runtime error in `rec`.

I think this is a general problem with all runtime-error events.

Please view or discuss this issue at 
https://github.com/w3c/mediacapture-record/issues/53 using your GitHub
Received on Wednesday, 13 April 2016 16:19:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:36 UTC