- 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