- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 8 Oct 2014 10:51:59 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Andrew Wilson <atwilson@google.com>, WHATWG List <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>, Jonas Sicking <jonas@sicking.cc>
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