- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 8 Oct 2014 11:37:43 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Andrew Wilson <atwilson@google.com>, WHATWG List <whatwg@whatwg.org>, Jake Archibald <jaffathecake@gmail.com>, Peter Beverloo <beverloo@google.com>
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 more of a coding pattern thing than an expectation thing. For example in gecko we often implement security checks by calling functions that throw exceptions if the security check failed. Mainly because this means less typing. So rather than writing: function implDOMThingy(x, y, z) { if (!callerCanAccess(x)) throw Error(...); if (!isSameOrigin(x,y)) throw Error(...); ... do stuff here ... } we write function implDOMThingy(x, y, z) { assertCanAccess(x); assertSameOrigin(x,y); ... do stuff here ... } So assertCanAccess/assertSameOrigin throws exceptions if a given security check doesn't pass. Not because the security function was called the wrong way or otherwise had an error, but because it makes callsites easier to write. However the experience that I personally have with this pattern is that it requires that the throwing function takes care of everything that needs to happen when an exception is thrown. For us that meant things like log errors to the developer console. So this is more appropriate in places when the throwing function provides a complete package of functionality. This also means that the functions are less reusable. Since they don't just do one thing. But it is quite awesome when you have such a resuable package that you can use in several callsites. Definitely makes the code less cluttered. But I think that's an indication that we should not do that here. I would for example expect that authors want to put up some UI to the user indicating that the reason some feature isn't working is because the user has denied access. / Jonas
Received on Wednesday, 8 October 2014 18:38:38 UTC