Why not define a standard helper function

[tmikov]

This is a continuation of the discussion here: #23 (comment)

There are a couple of obvious solutions that don't require changing the syntax:

• Error.throwHelper(x) with special logic to discard the topmost frame.
• Error.throwHelper(e) with an Error parameter.

@ljharb objected:

This [special logic to discard the topmost frame] is not an option, both because stacks aren't in the spec and because making a specific function magic in this regard would be profoundly problematic.

My response to that is that if stacks aren't in the spec, then 90% of the motivation for this proposal disappears. In any case it would be a QoI issue. It is not any more magical than Error already is.

[ljharb]

Error is indeed already magical. New forms of magic must be avoided.

Stacks exist, so the motivation for this proposal is unchanged - not being in the spec just means we can't use the spec to alter or constrain them.

[rbuckton]

This is already covered in the explainer: https://github.com/tc39/proposal-throw-expressions?tab=readme-ov-file#other-notes

[tmikov]

@rbuckton I don't think it was satisfactory covered. Specifically this seems incorrect:

The __throw helper will appear in err.stack in a host environment.

[rbuckton]

A user-defined __throw helper would, barring presence and use of Error.captureStackTrace. The 2nd and 3rd bullet points are relevant, however.

If an engine optimizes Error.throw(err), it must also be concerned with const __throw = Error.throw; __throw(err), or const obj = { throw: Error.throw }; obj.throw(err).

[hax]

A real function/method has problem, but as I suggested, we could consider meta method: do.throw(error).

[ljharb]

That would indeed be a viable approach - but only because it's syntax, which is what this issue seems to be trying to avoid.

[hax]

I think people generally don't mind whether it's a real method, and not really try to avoid syntax. It's all about ergonomics -- instead of forcing parens (throw err), method (whether it's real or meta method) has better ergonomics.

[theScottyJam]

How do you want your pseudo function call, JavaScript style do.throw(...) or lisp style (throw ...) :)

[ljharb]

@theScottyJam the former would be fine, but would be syntax, as would the latter.

[Jack-Works]

I don't understand why you need to "discard the topmost frame" at the first place. Error stacks are bound to where they are created, not where they are thrown (and this is true for Firefox, V8, and Safari).

[ljharb]

@Jack-Works your exact example shows it pointing to the throw e line.

[Jack-Works]

@Jack-Works your exact example shows it pointing to the throw e line.

but the error stack is not

[ljharb]

You're correct, but that still results in user confusion.

[Jack-Works]

You're correct, but that still results in user confusion.

if it is a built-in function, this won't happen.