Spell out stack hiding in more detail / maybe align with built-ins

[domenic]

In today's TC39 it became clear we need more details about the intention of this proposal with regard to hiding of stack frames. Although this will be tricky to specify given that the spec has no notion of stack frames, and tc39/proposal-error-stacks doesn't help (since it only specifies a format and not the contents), we need to at least be clearer in the proposal.

In particular, it was noted that the idea of completely omitting the stack frames does not match the way in which built-in functions are implementation-hidden by today's browsers. For example, check https://jsbin.com/celomim/edit?html,console,output , which does x.map(Number). Note that:

• Number shows up in the stack, with no filename/line number
• map shows up in the stack, with no filename/line number
• No helpers that Number or Array call show up in the stack, since those are implementation details of the engine's implementation of Number and Array.

My personal preference would be to align with the same sort of strategy browser-built-ins use. But, I haven't thought through how to specify that in detail, or whether it meets the encapsulation needs---especially for @michaelficarra's use cases.

One big TODO here is we want to incorporate @michaelficarra's presentation's examples about secret-disclosure into the README, to make it easier to validate and reason about proposal tweaks which might impact those.

[ljharb]

It's worth calling out explicitly that this can hide frames from the top level of a Module as well (and presumably from a Script?)

[domenic]

It's worth calling out explicitly that this can hide frames from the top level of a Module as well (and presumably from a Script?)

It's a good question whether it would do that. I wasn't consciously aware that such frames existed, but of course they do.

[michaelficarra]

I forgot about this issue when I created #23 with my thoughts on the topic. I'll just cross-reference for now, and we can close one or the other as duplicate later.

[michaelficarra]

This has been resolved. The new capabilities we want to give developers are

• the function does not appear in stack traces
• the function has no file attribution or position info in stack traces
• the function is rendered as a NativeFunction by Function.prototype.toString

Conveniences for the following were rejected

• the function's length property is not necessarily based on its parameter list
• the function's name property is not necessarily based on the syntactic binding