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

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

From: jan-ivar via GitHub <sysbot+gh@w3.org>
Date: Tue, 12 Apr 2016 01:01:42 +0000
To: public-media-capture@w3.org
Message-ID: <issues.opened-147601454-1460422901-sysbot+gh@w3.org>
jan-ivar has just created a new issue for 

== Error member in an Event for runtime-errors is a 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-main/issues/337 using your GitHub 
Received on Tuesday, 12 April 2016 01:01:44 UTC

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