Not sure about "Not an Error" and "try ... else ..."

[doodadjs]

I think the Cancel class could still inherit from Error. And instead of "try ... else ...", I'm thinking of :

try
    ....
catch(Cancel err) {
    ...
}
catch([TypeError, SyntaxError] err) {
    ...
}
...

EDIT: Fix markup

[ljharb]

That would be "catch guards", which would be an entirely different and complex proposal - and certainly not part of this one.

[domenic]

Yep. See the document in this repo explaining why cancelations are not errors. This is a fundamental part of the proposal and not going to change.

[Volune]

@ljharb Shouldn't the try ... else ... itself be part of another proposal, being a short syntax for a specific case of conditional catch.

I feel that the try ... else ... leaves a lot of questions

• It will be kind of the expected syntax to catch errors, how people coming from other languages will adapt?

• Can you chain else and catch

  try {
      // ...
  } else (e) {
      // on error
  } catch (c) {
      // on cancel
  } finally {
      // ...
  }

• How try ... else ... will make other proposals (for example about conditional catches) easier or more difficult?
• The next time a similar situation happens, will that introduce a try ... otherwise ... syntax?
• Should try ... else ... exclude Cancel instances, or should it filter Error instances?

[domenic]

All of those questions have answers in this repository and the spec. Please read the material you are critiquing.

[bergus]

@domenic Those are all valid questions. Why else? does not answer the first, third and fourth questions. The spec proposal does answer the second and fifth question, but without explanation or discussion why that is so. #35 does make a case against try {…} catch(…) {…} else(…) {…} but not against try {…} else(…) {…} catch(…) {…}.