Discuss
  • Standardizing conditional try/catch

Standardizing conditional try/catch

# Zach Lym (8 years ago)

Firefox supports the following conditional catch syntax:

try {
    let result = await ();
} catch (e if e instanceof ErrorType) {
    ...
}

This was originally implemented in Spidermonkey as part of an ES proposal around 2000, but it was rejected for unknown reasons 0. A 2012 email to this list suggesting standardization of the syntax was passed over in favor of waiting for a generic pattern matching facility 0. Later discussion suggests that the pattern matching proposal would have been very slow 2. A proposal for a Java-like type-based conditional was proposed in 2016, but was criticized for lacking generality 2.

If the above summary is accurate, I would like to try to standardize the vanilla syntax once again. It's imperative, general, and doesn't preclude the use of any hypothetical pattern matching functionality.

Javascript's control flow has improved dramatically in recent years: promises got rid of callbacks, async/await clipped promise chains, and classes make it easy to create custom Error objects that preserve stacktraces. Conditional catch is the last bit of syntax needed to make JS look like it was designed to handle asynchronous functions.

Thoughts?

-Zach Lym

# Jordan Harband (8 years ago)

instanceof doesn't work across realms (iframes, for example). If we introduced conditional catch blocks, I'd want a more reliable matching mechanism than instanceof.

# Michael J. Ryan (8 years ago)

The if condition doesn't need to be limited to instance of...

catch (err if !isNaN(err.status))

Aside: entering code in a phone is hard...

# kdex (8 years ago)

I'm not sure if embedding this idea into the language will make future ideas about true pattern matching harder to implement or not. Destructuring assignments are pretty slow from what I've measured, and they still made it in, so I hardly see performance being a showstopper here.

# Jordan Harband (8 years ago)

If the condition can be just "any javascript", wouldn't that potentially impede optimizations? Hopefully implementors can weigh in here, since non-implementor performance intuition (like mine) is often off base.

# T.J. Crowder (8 years ago)

I don't see optimization being a big deal, this is exception processing after all.

I was also thinking any expression:

try {
    // ...
}
catch (e if arbitraryExpression1Here) {
    // ...handle case 1
}
catch (e if arbitraryExpression2Here) {
    // ...handle case 2
}

...which would essentially be:

try {
    // ...
}
catch (e) {
    if (arbitraryExpression1Here) {
        // ...handle case 1
    } else if (arbitraryExpression2Here) {
        // ...handle case 2
    } else {
        throw e;
    }
}

...but without messing up the reported source of the error/stack (I'm looking at you, IE11).

-- T.J. Crowder

# Michał Wadas (8 years ago)

Is there a serious push to add pattern matching to language? Does any popular dynamically typed language have pattern matching? I read that TC39 agreed on adding pattern matching to language in March 2013. 4 years later we don't have even stage 0 proposal - so I would consider it to be a dead end or wishful thinking.

# kdex (8 years ago)

Well, there has been some discussion of potentially adding something like static type hints at some point in the future. Pattern matching is a feature that inevitably requires type information at runtime.

So as long as the "optional typing" story isn't dead, I would assume that pattern matching isn't quite dead either, it's just not in the currently possible scope of things. ECMAScript wouldn't be the only language which would have taken years to come around to implementing type hinting: IIRC Python got its type hinting feature pretty late, too.

# Michael J. Ryan (8 years ago)

Could also do like C# does and treat just throw; as an explicit rethrow...

I'm also not sure a lot of optimizations are needed as this is exception handling as otherwise mentioned.

# Michael J. Ryan (8 years ago)

Along a similar vein, is it time to discuss optional typing a la flow/typescript which seem to be going a very similar direction with different tooling?

Though I'm really unsure about the need/bloat beyond tooling and kind of feel that generic expression support for catch blocks may be enough.

# Zach Lym (8 years ago)

I read that TC39 agreed on adding pattern matching to language in March 2013. 4 years later we don't have even stage 0 proposal - so I would consider it to be a dead end or wishful thinking.

Exactly, this proposal has been kicking around for ~15 years but keeps getting deferred in favor of "something better." I would be all for a special syntax using type hints or targeting easier-to-optimize subsets, but they can be added later.

This proposal introduces the minimum number of features needed to handle the dynamic nature of JS.

Thank you, -Zach Lym

# kdex (8 years ago)

But then, we might be adding new syntax twice to solve the same problem. First specifically, then generally. The latter likely using an entirely different syntax, making the former syntax obsolete. Why not start speccing out some details for an optional typing proposal instead, so we can get the ball rolling for true pattern matching?

# Zach Lym (8 years ago)

Why not start speccing out some details for an optional typing proposal

instead, so we can get the ball rolling for true pattern matching?

Every serious typing proposals has flatlined 0 and pattern matching requires consensus on deep changes to JS that are very contentious 1:

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. 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 time overhead. It has to work as fast as traditional conditionals for anything beyond unapplying. It cannot slow down parsing or compilation more than marginally. It has to also satisfy the community and its needs.

I don't want to wait another decade for JS to have a clean async programming syntax.

Besides, what does the match syntax really get you in this case? Match is useful for dispatching single function calls and making converting long chains of horizontal if statements into vertical ones. It's not a general purpose replacement for if/else blocks.

Thank you, -Zach Lym

catch-blocks#content

# Alexander Jones (8 years ago)

Any future matching syntax would clearly support the special cases people want to codify now. It might be that the best possible syntax is lost, but e.g. ASI alone is probably a much bigger cause of syntax showstoppers to be worried about. IMO, let it build up, then we can start thinking about a syntax overhaul another day. The chances are that We Ain't Gonna Need It.

# Isiah Meadows (8 years ago)

It's possible to add a "[No LineTerminator here]" constraint when necessary, as was done for async functions.

As for pattern matching, if you start paying attention to features of newer programming languages, especially those just getting past their hype stage (like Kotlin, Rust, and Swift), that YAGNI argument is starting to seem harder to accept.

Pattern matching is to conditionals as async/await is to async tasks - it lifts the logic from fairly imperative, low level form to a high level, declarative form, with only a small loss of low-level control.

Isiah Meadows me at isiahmeadows.com

# Alexander Jones (8 years ago)

To be clear I was talking about advanced pattern matching for exception handling. Y(probably)AGNI?

# Isiah Meadows (8 years ago)

I want advanced pattern matching, but not something specific to error handling.

On Thu, Mar 23, 2017, 06:01 Alexander Jones <alex at weej.com> wrote:

To be clear I was talking about advanced pattern matching for exception handling. Y(probably)AGNI?

On Tue, 21 Mar 2017 at 05:08, Isiah Meadows <isiahmeadows at gmail.com> wrote:

It's possible to add a "[No LineTerminator here]" constraint when necessary, as was done for async functions.

As for pattern matching, if you start paying attention to features of newer programming languages, especially those just getting past their hype stage (like Kotlin, Rust, and Swift), that YAGNI argument is starting to seem harder to accept.

Pattern matching is to conditionals as async/await is to async tasks - it lifts the logic from fairly imperative, low level form to a high level, declarative form, with only a small loss of low-level control.

Isiah Meadows me at isiahmeadows.com

On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <alex at weej.com> wrote:

Any future matching syntax would clearly support the special cases people want to codify now. It might be that the best possible syntax is lost, but e.g. ASI alone is probably a much bigger cause of syntax showstoppers to

be

worried about. IMO, let it build up, then we can start thinking about a syntax overhaul another day. The chances are that We Ain't Gonna Need It.

On 19 March 2017 at 22:47, kdex <kdex at kdex.de> wrote:

But then, we might be adding new syntax twice to solve the same problem. First specifically, then generally. The latter likely using an entirely different syntax, making the former syntax obsolete. Why not start speccing out some details for an optional typing proposal instead, so we can get the ball rolling for true pattern matching?

On Sunday, March 19, 2017 11:18:25 PM CET Zach Lym wrote:

I read that TC39 agreed on adding pattern matching to language in March 2013. 4 years later we don't have even stage 0 proposal - so I would consider it to be a dead end or wishful thinking.

Exactly, this proposal has been kicking around for ~15 years but keeps getting deferred in favor of "something better." I would be all for a special syntax using type hints or targeting easier-to-optimize

subsets,

but they can be added later.

This proposal introduces the minimum number of features needed to

handle

the dynamic nature of JS.

Thank you, -Zach Lym

On Sun, Mar 19, 2017 at 8:23 AM, kdex <kdex at kdex.de> wrote:

Well, there has been some discussion of potentially adding something like static type hints at some point in the future. Pattern matching is a feature that inevitably requires type information at runtime.

So as long as the "optional typing" story isn't dead, I would assume that pattern matching isn't quite dead either, it's just not in the currently possible scope of things. ECMAScript wouldn't be the only language which would have taken years to come around to implementing type hinting: IIRC Python got its type hinting feature pretty late, too.

On Sunday, March 19, 2017 4:22:26 PM CET Michał Wadas wrote:

Is there a serious push to add pattern matching to language? Does any popular dynamically typed language have pattern matching? I read that TC39 agreed on adding pattern matching to language in March 2013. 4 years later we don't have even stage 0 proposal - so I

would

consider it to be a dead end or wishful thinking.

On Sat, Mar 18, 2017 at 5:16 PM, kdex <kdex at kdex.de> wrote:

I'm not sure if embedding this idea into the language will make future ideas about true pattern matching harder to implement or not. Destructuring assignments are pretty slow from what I've

measured,

and they still made it in, so I hardly see performance being a showstopper here.

On Saturday, March 18, 2017 12:18:22 PM CET Michael J. Ryan

wrote:

The if condition doesn't need to be limited to instance of...

catch (err if !isNaN(err.status))

Aside: entering code in a phone is hard...

instanceof doesn't work across realms (iframes, for example). If we

introduced conditional catch blocks, I'd want a more reliable matching

mechanism than instanceof.

On Fri, Mar 17, 2017 at 5:01 PM, Zach Lym <zachlym at indolering.com> wrote:

Firefox supports the following conditional catch syntax:

try {
    let result = await ();
} catch (e if e instanceof ErrorType) {
    ...
}

This was originally implemented in Spidermonkey as part of

an

ES proposal

around 2000, but it was rejected for unknown reasons [0]. A 2012 email to

this list suggesting standardization of the syntax was

passed

over in

favor

of waiting for a generic pattern matching facility [0][1]. Later discussion suggests that the pattern matching proposal would have been very

slow [2]. A proposal for a Java-like type-based conditional was proposed in

2016, but was criticized for lacking generality [2].

If the above summary is accurate, I would like to try to standardize

the

vanilla syntax once again. It's imperative, general, and doesn't preclude

the use of any hypothetical pattern matching functionality.

Javascript's control flow has improved dramatically in

recent

# Zach Lym (8 years ago)

Pattern matching is to conditionals as async/await is to async tasks - it lifts the logic from fairly imperative, low level form to a high level, declarative form, with only a small loss of low-level control.

Are you arguing that we should have skipped promises and gone straight to async/await?

FWIW, this in itself is not a trivial change as it requires extra work for the debugger.

Thank you, -Zach Lym

# Isiah Meadows (8 years ago)

Inline

On Sun, Mar 26, 2017 at 10:23 PM, Zach Lym <zachlym at indolering.com> wrote:

Pattern matching is to conditionals as async/await is to async tasks - it lifts the logic from fairly imperative, low level form to a high level, declarative form, with only a small loss of low-level control.

Are you arguing that we should have skipped promises and gone straight to async/await?

No. My analogy was a bit more meta than that, and I was referring to the difference between promise chaining and async-await control flow - async-await abstracts over the details of task scheduling. Similarly, instead of low-level conditionals, pattern matching just abstracts over the details of conditional ordering.

FWIW, this in itself is not a trivial change as it requires extra work for the debugger.

I get that it'd be difficult for the debugger to handle.

Thank you, -Zach Lym

On Sat, Mar 25, 2017 at 6:29 PM, Isiah Meadows <isiahmeadows at gmail.com> wrote:

I want advanced pattern matching, but not something specific to error handling.

On Thu, Mar 23, 2017, 06:01 Alexander Jones <alex at weej.com> wrote:

To be clear I was talking about advanced pattern matching for exception handling. Y(probably)AGNI?

On Tue, 21 Mar 2017 at 05:08, Isiah Meadows <isiahmeadows at gmail.com> wrote:

It's possible to add a "[No LineTerminator here]" constraint when necessary, as was done for async functions.

As for pattern matching, if you start paying attention to features of newer programming languages, especially those just getting past their hype stage (like Kotlin, Rust, and Swift), that YAGNI argument is starting to seem harder to accept.

Pattern matching is to conditionals as async/await is to async tasks - it lifts the logic from fairly imperative, low level form to a high level, declarative form, with only a small loss of low-level control.

Isiah Meadows me at isiahmeadows.com

On Mon, Mar 20, 2017 at 8:42 PM, Alexander Jones <alex at weej.com> wrote:

Any future matching syntax would clearly support the special cases people want to codify now. It might be that the best possible syntax is lost, but e.g. ASI alone is probably a much bigger cause of syntax showstoppers to be worried about. IMO, let it build up, then we can start thinking about a syntax overhaul another day. The chances are that We Ain't Gonna Need It.

On 19 March 2017 at 22:47, kdex <kdex at kdex.de> wrote:

But then, we might be adding new syntax twice to solve the same problem. First specifically, then generally. The latter likely using an entirely different syntax, making the former syntax obsolete. Why not start speccing out some details for an optional typing proposal instead, so we can get the ball rolling for true pattern matching?

On Sunday, March 19, 2017 11:18:25 PM CET Zach Lym wrote:

I read that TC39 agreed on adding pattern matching to language in March 2013. 4 years later we don't have even stage 0 proposal - so I would consider it to be a dead end or wishful thinking.

Exactly, this proposal has been kicking around for ~15 years but keeps getting deferred in favor of "something better." I would be all for a special syntax using type hints or targeting easier-to-optimize subsets, but they can be added later.

This proposal introduces the minimum number of features needed to handle the dynamic nature of JS.

Thank you, -Zach Lym

On Sun, Mar 19, 2017 at 8:23 AM, kdex <kdex at kdex.de> wrote:

Well, there has been some discussion of potentially adding something like static type hints at some point in the future. Pattern matching is a feature that inevitably requires type information at runtime.

So as long as the "optional typing" story isn't dead, I would assume that pattern matching isn't quite dead either, it's just not in the currently possible scope of things. ECMAScript wouldn't be the only language which would have taken years to come around to implementing type hinting: IIRC Python got its type hinting feature pretty late, too.

On Sunday, March 19, 2017 4:22:26 PM CET Michał Wadas wrote:

Is there a serious push to add pattern matching to language? Does any popular dynamically typed language have pattern matching? I read that TC39 agreed on adding pattern matching to language in March 2013. 4 years later we don't have even stage 0 proposal - so I would consider it to be a dead end or wishful thinking.

On Sat, Mar 18, 2017 at 5:16 PM, kdex <kdex at kdex.de> wrote:

I'm not sure if embedding this idea into the language will make future ideas about true pattern matching harder to implement or not. Destructuring assignments are pretty slow from what I've measured, and they still made it in, so I hardly see performance being a showstopper here.

On Saturday, March 18, 2017 12:18:22 PM CET Michael J. Ryan wrote:

The if condition doesn't need to be limited to instance of...

catch (err if !isNaN(err.status))

Aside: entering code in a phone is hard...

instanceof doesn't work across realms (iframes, for example). If we

introduced conditional catch blocks, I'd want a more reliable matching

mechanism than instanceof.

On Fri, Mar 17, 2017 at 5:01 PM, Zach Lym <zachlym at indolering.com> wrote:

Firefox supports the following conditional catch syntax:

try {
    let result = await ();
} catch (e if e instanceof ErrorType) {
    ...
}

This was originally implemented in Spidermonkey as part of an ES proposal

around 2000, but it was rejected for unknown reasons 0. A 2012 email to

this list suggesting standardization of the syntax was passed over in

favor

of waiting for a generic pattern matching facility 0. Later discussion suggests that the pattern matching proposal would have been very

slow [2]. A proposal for a Java-like type-based conditional was proposed in

2016, but was criticized for lacking generality [2].

If the above summary is accurate, I would like to try to standardize

the

vanilla syntax once again. It's imperative, general, and doesn't preclude

the use of any hypothetical pattern matching functionality.

Javascript's control flow has improved dramatically in recent years:

promises got rid of callbacks, async/await clipped promise chains, and

classes make it easy to create custom Error objects that preserve stacktraces. Conditional catch is the last bit of syntax needed to

make JS

look like it was designed to handle asynchronous functions.

Thoughts?

-Zach Lym

content-10

[2]:

esdiscuss.org/topic/error-type-specific-try-catch-bl ocks#content-14

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

es-discuss mailing list es-discuss at mozilla.org, mail.mozilla.org/listinfo/es-discuss

Isiah Meadows me at isiahmeadows.com

# Zach Lym (8 years ago)

On Sun, Mar 26, 2017 at 10:23 PM, Zach Lym <zachlym at indolering.com> wrote:

Pattern matching is to conditionals as async/await is to async tasks - it lifts the logic from fairly imperative, low level form to a high level, declarative form, with only a small loss of low-level control.

Are you arguing that we should have skipped promises and gone straight to async/await?

No. My analogy was a bit more meta than that, and I was referring to the difference between promise chaining and async-await control flow - async-await abstracts over the details of task scheduling. Similarly, instead of low-level conditionals, pattern matching just abstracts over the details of conditional ordering.

I totally agree with you that a pattern matching API would be better, but unless you can come up with a syntax that can be enhanced progressively....

-Zach Lym

# Isiah Meadows (8 years ago)

It would take me a bit, and I've been contemplating syntax mentally for a while. But I may post a gist soonish