Examples with try/catch

[mmun]

Firefox implements non-standard conditional catch clauses like

try {
  myCode();
} catch (error if error instanceof MyError) {
  // ...
}

I think this is a useful shorthand as it helps avoid accidental trolls with forgetting to rethrow errors you're not interested in.

The reason I bring it up in this proposal is that it is often mentioned that pattern matching is in some sense a blocker for standardizing conditional catches. e.g. here or here.

Do you see a path for applying this proposal to conditional catches?

[bterlson]

I don't have any examples, as I'm not sure how the current proposal could look. I think this is an important use case to consider. I am hoping we can have a binary operator that takes a Pattern for it's RHS, so you could do if error ~= MyError with conditional catch clauses at least.

[mmun]

@bterlson Ah, that seems useful to have an expression form.

I was thinking of a statement form that could be unified across if, while and catch.

As a motivating example, in the Rust programming language there is basic control flow like

if my_bool { ... }

while my_bool { ... }

Additionally, there are pattern matching forms for both of these. The pattern matching forms let you check if a pattern matches and destructure the pattern if it does.

if let Ok(value) = my_result { ... }

while let Some(value) = my_iter.next() { ... }

Back to JavaScript, I could imagine a similar sort of construct (don't focus on the exact syntax too much 😸)

if (let { x, y, z } = value) { ... }

while (let { done: false, value } = iter.next()) { ... }

try { ... } catch (let { x, y, z } = value) { ... }

[bterlson]

I can see statement forms being useful but I'm not sure how they should look. It should at least be clear that pattern matching semantics are used (rather than normal destructuring assignment semantics which I would probably expect in your examples above).

[mmun]

Oops, that's an obvious mistake on my part. Let me trade that strawman in for another

if (match { x, y, z } = value) { ... }

while (match { done: false, value } = iter.next()) { ... }

try { ... } catch (match { x, y, z } = value) { ... }

[jmar777]

I'm admittedly over my head when it comes to grammar definitions, but is it possible to make MatchExpressionClauses a valid catch body? E.g.,

try {
  ...
} catch (err) {
  TypeError: /* handle it */,
  MyCustomError: /* handle it */,
  else: /* ... */
}

So, the catch grammar rules might introduce a new CatchBody construct, which would be defined as something like the following:

CatchBody :
    Block[?Yield, ?Await, ?Return]
    MatchExpressionClauses

(forgive me, people who actually understand how I bludgeoned the above...)

[rattrayalex]

@jmar777 that particular syntax would be unlikely on the grounds that it wouldnt be backwards compatible.

More likely would probably be multiple catch clauses, eg;

try {}
catch (FooError as e) {}
catch (BarError as e) {}
catch (Baz as b) {}
catch (err) {}

(though as is not currently on the table, as far as I know)

[jmar777]

Ugh, I always forget about labels. I think my example above would only be valid using the new grammar rules, but yeah, a single match expression would be syntactically equivalent to label: <statement>.

[zkat]

Hey y'all! #65 has gotten merged, and a lot of issues have become irrelevant or significantly changed in context. Because of the magnitude of changes and subtle differences in things that seem similar, we've decided to just nuke all existing issues so we can start fresh. Thank you so much for the contributions and discussions and feel free to create new issues if something seems to still be relevant, and link to the original, related issue so we can have a paper trail (but have the benefit of that clean slate anyway).

As far as this particular suggestion goes: there's a Beyond This Spec section that explicitly mentions catch patterns, so I hope this sort of thing is considered in the future! I don't think this specific proposal should try to spec that feature, though, as being conservative about scope will be very helpful to getting this thing out the door and reaching consensus on the feature.