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

On Wed, Oct 8, 2014 at 10:39 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> You keep ignoring the past "turns out we like using async errors for
>> 'soft failures' of this kind, and have done it lots of times, and
>> nobody seems to complain" argument.
>
> A user saying no to notifications is not an error. You ask the user to
> make a decision, the user decides. Either way is a success. An error
> would be invoking the method in the wrong way.

This is 100% arguable, and based solely on the *precise* manner in
which you are assigning semantics to the name.

If we named the method "getNotifier()", and it requested permission as
a side-effect, would you call failure to get the notifier due to
refusing permission an exceptional situation?

>> Do you dislike img.onerror firing when the image doesn't load?  (And
>> same for all the other resource-loading elements.)
>
> That makes sense. Network errors are rather exceptional. Note that it
> does not error for a 404 (unless it can't decode the response, which
> again, is rather exceptional).
>
>
>> Do you dislike
>> geolocator.getCurrentPosition calling the failure callback when the
>> user refuses permission?
>
> I would expect that to be done differently today, yes.

Why?  getCurrentPosition is asking for the current permission.  If you
fail to get the current position, why would you call that a success?
What would you even pass to the success callback?  A neutered position
object?  A position object with default values, plus an extra field
saying "lol no this isn't real"?

~TJ

Received on Wednesday, 8 October 2014 17:52:46 UTC