- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 8 Oct 2014 10:58:21 -0700
- To: Olli Pettay <olli@pettay.fi>
- 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:54 AM, Olli Pettay <olli@pettay.fi> wrote: > On 10/08/2014 08:03 PM, Tab Atkins Jr. wrote: >> >> On Wed, Oct 8, 2014 at 9:16 AM, Anne van Kesteren <annevk@annevk.nl> >> wrote: >>> >>> On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola >>> <domenic@domenicdenicola.com> wrote: >>>> >>>> What I find interesting here is the claim that people find try/catch >>>> annoying or distasteful. >>> >>> >>> I don't think you should need try/catch for a common failure case. >>> That is all. So yes, agreed with Tobie et al. >> >> >> You keep arguing from the future "rejections become errors" position. >> 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. >> >> Do you dislike img.onerror firing when the image doesn't load? (And >> same for all the other resource-loading elements.) Do you dislike >> geolocator.getCurrentPosition calling the failure callback when the >> user refuses permission? Do you dislike IDB firing error events on >> several types of failure, ranging from exceptional to mundane? >> >> If there are any of these you do *not* dislike, why? And why doesn't >> the logic from those apply to this situation? >> >> On Wed, Oct 8, 2014 at 9:18 AM, Domenic Denicola >> <domenic@domenicdenicola.com> wrote: >>> >>> Ah, this is the crux of our minor-disagreement, I think. >>> >>> IMO using try/catch for a common failure case is fine, *as long as you >>> want that failure to bubble up the call stack*. E.g., if you want to handle >>> it at a higher level along with other failures, or if you want to ignore the >>> possibility of failure except in how errors get sent to `window.onerror`. >>> >>> Now, I think we're likely in *agreement* that you don't actually want to >>> do this for requestPermission---you should handle it as soon as possible. >>> But our reasoning is different, and now I understand why. >> >> >> The problem here is that try/catch *is* distasteful, while promise >> rejection isn't, and it's all ergonomics. >> >> * try/catch produces rightward drift, promise reject handlers do not >> * errors bubble up indefinitely until they're caught, breaking all of >> your code. > > (off topic to Notifications) > That is a main point of exceptions. If your code is horribly broken, > like wrong params passed to some method, execution should stop asap. > The fact that Promise returning functions don't throw immediately is a crazy > setup > since one may just ignore and not notice at all the rather bad error in the > program logic. As was stated in a recent bug thread you were participating in, we got feedback from authors using IDB that they actually quite disliked having to handle *some* errors via try/catch and *other* errors via error callbacks, and would have preferred they all go through the error callback. ~TJ
Received on Wednesday, 8 October 2014 17:59:07 UTC