In JavaScript, why is putting the thrown value on the line after `throw` a syntax error, and how do you throw from an expression position such as an arrow function's concise body or the right-hand side of `??`?

## Two separate facts, often confused This question bundles two independent pieces of the grammar: a restricted production about newlines, and the statement-vs-expression distinction. They bite in different places. ## Restricted production: no newline after `throw` The ECMAScript grammar for a throw statement is written as: ``` throw [no LineTerminator here] Expression ; ``` That bracketed annotation is a **restricted production**. It means the parser refuses to accept a line break between the keyword and its operand. So this fails to parse: ```js throw new Error('nope'); // SyntaxError: Illegal newline after throw ``` Why an error rather than something weird-but-legal? Automatic semicolon insertion (ASI) reacts to a restricted production by terminating the statement at the line break. That would yield `throw;`, and `throw;` is not a valid statement — the grammar has no argument-less form. With no valid parse available, the engine reports a syntax error at parse time, before anything runs. The contrast with `return` is the memorable part. `return` is *also* a restricted production, but `return;` **is** a valid statement. So: ```js function f() { return { ok: true }; // returns undefined; the object literal is dead code } ``` silently returns `undefined`. Two identically-shaped grammar rules produce a loud failure in one case and a silent bug in the other, purely because of whether the bare form is legal. `throw` is the friendlier of the two: it cannot fail quietly. The practical rule is simply to keep the value on the same line as the keyword. If the expression is long, break *inside* it: ```js throw new Error( `unsupported format: ${format}` ); ``` That is fine — the line break is inside the argument list, not between `throw` and `new`. ## `throw` is a statement, not an expression A statement produces no value, so `throw` cannot go where the language expects one. All of these are syntax errors: ```js const x = flag ? compute() : throw new Error('no'); // ternary branch const y = value ?? throw new Error('missing'); // ?? right operand const f = () => throw new Error('boom'); // concise arrow body const z = (throw new Error('boom')); // parentheses do not help ``` Parenthesising does not help, because parentheses group *expressions*, and there is no throw-expression to group. (A TC39 proposal to add throw expressions has been floated but is not part of the language, so do not write code that assumes it.) ### Getting a throw into an expression position The trick is that a **function call is an expression**, and a function body may contain any statement. So wrap the throw in a function and call it. With an arrow that has a block body: ```js const f = () => { throw new Error('boom'); }; ``` Immediately invoked, inline: ```js const port = process.env.PORT ?? (() => { throw new Error('PORT is required'); })(); ``` That works but reads badly at every call site. The usual production shape is a named helper: ```js function fail(message) { throw new Error(message); } const port = config.port ?? fail('port is required'); const mode = flag ? 'fast' : fail('mode not set'); const { id } = payload ?? fail('payload missing'); ``` `fail(...)` is an ordinary call expression, so it is legal in a ternary branch, as the right operand of `??` or `||`, in a default parameter value, and anywhere else a value belongs. It never returns — control leaves via the throw — which is exactly the semantics you wanted. ### Default parameters are a natural home for it ```js function connect(url = fail('url is required')) { return url; } ``` The default expression is only evaluated when the argument is omitted, so this gives a required-parameter check with no `if` statement in the body. ## Why interviewers ask this It separates people who have merely used `throw` from people who have read what it *is*. The newline rule shows you know restricted productions and how ASI behaves at them; the expression question shows you understand the statement/expression split well enough to work around it deliberately, instead of concluding that "you can't throw there".