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
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
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
>
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
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
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
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
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,
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 (
>
> } 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
@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
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
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
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
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
>
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
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,
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
>
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
19 matches
Mail list logo