proposal-throw-expressions: Should `throw throw x` be disallowed?

I believe that it should be allowed, as there are no issues with the runtime semantics and the syntax behaves similarly to void void x, which is allowed today. Disallowing it would be counterintuitive in relation to other unary expressions. Just disallowing throw throw x wouldn’t prevent throw (throw x) or throw (0, throw x) or throw void throw x, etc. Trying to disallow this in the spec would be a wild goose chase and would overcomplicate the specification.

It seems that disallowing throw throw x would be better left as a lint rule.

I don’t see why throw throw x should be disallowed, while throw (()=>{throw x})() is allowed…

I think throw throw x is strange but totally ok if throw is an expression. I also think we have a consensus on this.

Can we close this (non-)issue ?

Why would a debugger step into all of the throws? Only the innermost one is actually reached in the execution context.

Consider

throw hello();

function hello() {
  throw new Error();
}

would you expect the debugger to step through both in this case?

The committee feels the same. That doesn’t mean this is a “non-issue” or that it shouldn’t have been brought up, is all.

I concur with the general consensus that there is no reason to ban throw throw in the language itself and to leave it to linters/etc. to enforce any restrictions.

eslint absolutely would 😃 since the committee expressed what i’d describe as a strong unwillingness to try to ban these sorts of useless expressions (due to the grammar complexities involved, to be fair), it seems that it will be left to linters and styleguides to ban them.

I tend to agree. In userland terms, it’s similar to passing the result of a void returning function to another void returning function (a-la console.log(console.log('foo'))), which is allowed today.

Seeing how throw currently accepts any expression and throw x is proposed to be a valid expression, I agree that the syntax should be valid.

Another interesting question though is what’s the behavior in this case. The practical, expected behavior in my opinion is that the innermost operand to throw throw throw .... throw x is thrown in reality, and that the extra throws are no-ops.