Re: [whatwg] Notifications: making requestPermission() return a promise

On 01/10/14 14:21, Tab Atkins Jr. wrote:
> On Wed, Oct 1, 2014 at 9:18 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
>> On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> Wait, what?  Anytime you request something, not getting it is
>>> exceptional.  Not sure how you can make an argument otherwise.
>>
>> I would not expect a synchronous version of this method (were it to
>> exist) to have to use try/catch for anything other than invoking it
>> with an argument such as "TEST", which is clearly wrong. That's why I
>> don't think it's exceptional (e.g. warrants an exception/rejection).
> 
> And I wouldn't expect someone loading a FontFace synchronously to use
> try/catch to deal with loading errors, either, because that's super
> obnoxious.  Failure, though, is a standard rejection reason - it maps
> to the use of "onerror" events.

Isn't this just a problem that we have three possible outcomes:

* Permission grant

* Permission reject

* Invalid input data

And three possible ways of routing the code:

* Promise fulfilled

* Promise rejected

* Exception

But we are only using two of them? In that case something has to give;
you either need to disambiguate user grant vs user reject in the fulfill
function or user reject vs invalid data in the rejection function.
Neither seems obviously to have better ergonomics than the other.

Received on Wednesday, 1 October 2014 13:33:37 UTC