- From: James Graham <james@hoppipolla.co.uk>
- Date: Wed, 01 Oct 2014 14:33:05 +0100
- To: whatwg@lists.whatwg.org
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