- From: <bugzilla@jessica.w3.org>
- Date: Fri, 11 Apr 2014 19:05:17 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25268 David Dorwin <ddorwin@google.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|adrianba@microsoft.com |ddorwin@google.com --- Comment #2 from David Dorwin <ddorwin@google.com> --- (In reply to David Dorwin from comment #1) > Thus, instead of creating a useless session object (bug 25267), > implementations can reject the promise with an appropriate DOMException if > the specified initData was not used to create any of the existing active > (i.e. not closed) sessions for this MediaKeys object. Actually, per [1] we should not reject the promise. Instead we should resolve it with undefined or null. This is similar to how loadSession() resolves with undefined when the session is not found. This is also easier for applications to reason about: void onResolved(value) { if (!value) { // I must already have a session for this initData. return; } ... } I'm not sure whether undefined or null is technically more appropriate. It doesn't really affect applications, but we need to pick one. undefined makes sense when something couldn't be found. Maybe null makes more sense in this case because we explicitly chose to return a null object. > We might need a unique DOMException value so > that applications can easily check for and ignore this non-error rejection > of the Promise. Thus, there is no need for such a DOMException name. [1] https://github.com/w3ctag/promises-guide#rejections-should-be-used-for-exceptional-situations -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 11 April 2014 19:05:19 UTC