Re: Error-Type Specific try/catch Blocks

I still can't see why it's superior to standardizing SpiderMonkey non-standard syntax. ``` try { ... } catch(e if e instanceof Error) { } ``` I think it's rather inferior, because your doesn't allow C#-like exception filters. It saves you 14 characters, but limits your "easy" filters to

Re: Error-Type Specific try/catch Blocks

Shiny... On Fri, May 27, 2016, 05:06 Arthur Stolyar wrote: > Something wrong with prev link. > https://github.com/zenparsing/es-typed-catch > On May 27, 2016 12:00, "Arthur Stolyar" wrote: > >> If something, here seems to be another similar

Re: Error-Type Specific try/catch Blocks

Something wrong with prev link. https://github.com/zenparsing/es-typed-catch On May 27, 2016 12:00, "Arthur Stolyar" wrote: > If something, here seems to be another similar proposal: > https://github.com/zenparsing/es-typed-catch >

Re: Error-Type Specific try/catch Blocks

If something, here seems to be another similar proposal: https://github.com/zenparsing/es-typed-catch ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Error-Type Specific try/catch Blocks

TL;DR: I *really* want full pattern matching, but it's a very long and steep road to climb, and no one has gotten it right yet in a dynamic language [1]. None of the implementors will be okay with it until you demonstrate that it's both possible and practical to implement, with minimal memory and

Re: Error-Type Specific try/catch Blocks

Hmmm, can't find your proposal, mind to share the link directly? I did however find a comment from Brendan Eich 3 years ago that basically resonated with my idea that refutable patterns and matching is the way to go for conditional catch, and another thread from a year ago that this still is the

Re: Error-Type Specific try/catch Blocks

Pattern matching has been considered before, and the performance will suck if you consider things like `Point(x, y)`. It's very hard to optimize at runtime, and engines don't have time to optimize that statically. If you want to consider Clojure as an example of one that does this dynamically, it

Re: Error-Type Specific try/catch Blocks

This is another really far shot - but I'd rather suggest that we should redefine the role of `case` so that it's no longer just a part of the `switch` statement but something more generic, as well as introducing a `match` keyword to enable pattern matching, including the power of matching by type,

Re: Error-Type Specific try/catch Blocks

I offered a few syntaxes for this, perhaps the bitwise OR "|" would be better. On Fri, May 13, 2016 at 1:33 PM, Michał Wadas wrote: > > } catch (await FCL.load(...), await FCL.load(...)) (e) { > Then you have to override comma operator ( >

Re: Error-Type Specific try/catch Blocks

> } catch (await FCL.load(...), await FCL.load(...)) (e) { Then you have to override comma operator ( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Comma_Operator ) in one specific context... On Fri, May 13, 2016 at 7:14 PM, Joe Groseclose

Re: Error-Type Specific try/catch Blocks

@JoePea, that is one of the syntaxes I recommend in the proposal. @michalwadas The primary goal of this I think is to create a standard feature, but I do not see why an expression wrapped in parenthesis ultimately resulting in an error class would not be supported. Example: ... } catch

Re: Error-Type Specific try/catch Blocks

On 5/13/16 11:06 AM, Joseph Groseclose wrote: I sent this proposal via http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php# yesterday evening. Sharing it here now: https://github.com/benderTheCrime/error-type-specific-catch-proposal I'd like to understand the

Re: Error-Type Specific try/catch Blocks

Perhaps a syntax based on modules: ```js try {} catch (TypeError as e) {} // ... try {} catch (MyError as err) {} ``` On Fri, May 13, 2016 at 9:43 AM, Michał Wadas wrote: > I can't see why would your syntax be superior to SpiderMonkey extension > except saving few

Re: Error-Type Specific try/catch Blocks

I can't see why would your syntax be superior to SpiderMonkey extension except saving few characters. Can your syntax support code like this: async function foo() { try { throw new Error(); } catch(e if isNativeException(e)) { // special handler for DOM exceptions } catch(e

Re: Error-Type Specific try/catch Blocks

I've updated the proposal. See: https://github.com/benderTheCrime/error-type-specific-catch-proposal#about-spidermonkey-implementation On Fri, May 13, 2016 at 11:49 AM, Joseph Groseclose wrote: > Nevertheless, perhaps the non-standard implementation could work >

Re: Error-Type Specific try/catch Blocks

Nevertheless, perhaps the non-standard implementation could work hand-in-hand with the proposal, where SpiderMonkey could support both solutions in parallel for backward compatibility. I think that the proposed solution is more expressive. On Fri, May 13, 2016 at 11:26 AM, Claude Pache

Re: Error-Type Specific try/catch Blocks

Ah, that does somewhat throw a wrench in the system. I'm not sure what the committee's policy is on backwards compatibility and non-standard features. I find the SpiderMonkey handling you just brought to my attention to be a little clunky. Sent from my iPhone > On May 13, 2016, at 11:26 AM,

Re: Error-Type Specific try/catch Blocks

Note that SpiderMonkey has already nonstandard conditional catch clauses: ```js try { // ... } catch (e if e instanceof TypeError) { // } ``` —Claude > Le 13 mai 2016 à 17:06, Joseph Groseclose a écrit : > > I sent this proposal via >

Error-Type Specific try/catch Blocks

I sent this proposal via http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php# yesterday evening. Sharing it here now: https://github.com/benderTheCrime/error-type-specific-catch-proposal ___ es-discuss mailing list