- From: David Dorwin <ddorwin@chromium.org>
- Date: Wed, 1 Oct 2014 11:30:09 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: whatwg@lists.whatwg.org
On Wed, Oct 1, 2014 at 11:02 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 10/1/14, 1:59 PM, David Dorwin wrote: > >> Rejection also has the advantage of providing an exception, which can >> provide information (reason and message) to differentiate between >> potentially multiple causes. This is not possible when resolving with >> null. >> Providing such information would likely make development and debugging >> easier. >> > > If you were designing a sync API, would not the same arguments apply? So > you'd want to throw different kinds of exceptions to indicate "not > supported"? I would specify that DOMException with the name "NotSupportedError" be thrown. User agent implementations could provide more information in the message. (There might be other "non-exceptional" failures that would use different exception names.) However, it sounds like something not being supported by a UA would not be "exceptional," so an exception should not be thrown in this case. (This is no less expected than "the user declining notifications".) I guess the synchronous API would return null. That seems odd since an exception has historically been thrown in such cases. > > > -Boris > >
Received on Wednesday, 1 October 2014 18:30:57 UTC