- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Fri, 08 Apr 2016 20:19:44 +0000
- To: public-media-capture-logs@w3.org
@foolip good point. I shouldn't have taken that at face value. The
only other use I found was in
[workers](https://www.w3.org/TR/service-workers/#service-worker-container-error-event).
Agree file and line number don't make sense with events fired from
built-in code. Even an error property may be a bad idea, I see now,
because it encourages this pattern (which is why I wanted one):
```js
var rec = new MediaRecorder(stream);
rec.start();
var stopped = new Promise((resolve, reject) => {
rec.onstop = resolve;
rec.onerror = event => reject(event.error));
});
```
instead of being forced to do something like:
```js
var stopped = new Promise((resolve, reject) => {
rec.onstop = resolve;
rec.onerror = event => reject(new DOMException(event.message,
event.name));
});
```
The latter looks ugly, but we get file and line number (and stack)
pointing to the `onerror` line, which may be extremely helpful in long
promise-chains, whereas in the former case we get nothing.
> If it's only used for "Any error occured from the data channel" then
maybe a RTCDataChannelErrorEvent would be a better fit?
Don't forget https://github.com/w3c/mediacapture-record/issues/42.
Seems common to expect to find someplace shared. Pity `ErrorEvent` may
not be it.
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at
https://github.com/w3c/mediacapture-main/issues/335#issuecomment-207587778
using your GitHub account
Received on Friday, 8 April 2016 20:19:46 UTC