Honestly I'm really not sure how I feel about this. Guards are a huge deal. They're a big (and nice!) feature, it sounds like they bring a lot of complexity (specifying them, not using then). They'll likely require a lot of work and debate in order to make it in (or not).
I have a very real and very simple use case I run into constantly. Like you said - if I used Mozilla's JS engine I'd be able to do a conditional catch but I don't have the luxury of only developing for Mozilla (I'll use it in Firefox OS for sure though :) ). For example, I write a lot of node which doesn't have conditional catch. (I completely agree about type conditions not being the right solution - behavior seems like a much better option) You tell me I don't need to sell you this - who do I need to sell this to? What people do I convince in order to have better catch clauses that solve my problem in the spec? Thanks, Benjamin On Wed, Nov 20, 2013 at 10:56 PM, Brendan Eich <[email protected]> wrote: > Sam Tobin-Hochstadt wrote: > >> On Wed, Nov 20, 2013 at 12:35 PM, Brendan Eich<[email protected]> >> wrote: >> >>> > I don't quite understand what Benjamin is running into. >>> >> >> I think that Benjamin's point is that generators allow you to use >> synchronous programming models instead of async ones. Then your >> errors become exceptions instead of errback calls. So, whereas >> ES5-style JS features very few exceptions, ES6-style will feature more >> exceptions. This increases the pressure on exception handling to be >> nice, which it isn't because of the lack of catch guards. >> > > Yeah, if you read up, you'll see that this became clear just recently > in-thread. > > Yay for refutable patterns, including in catch heads. > > /be > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
