On Wed, Oct 1, 2014 at 11:02 AM, Boris Zbarsky <bzbar...@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 > >
