search

tc39 / proposal-function-implementation-hiding

JavaScript language proposal: function implementation hiding
https://ci.tc39.es/preview/tc39/ecma262/pull/1739
MIT License
98 stars 7 forks source link

Implementation of unhandled rejection/uncaught exception logging in Node.js #28

Closed misterdjules closed 4 years ago

misterdjules commented 4 years ago

Reading the following item:

What error stack traces the developer eventually sees on their screen when an unhandled exception or rejection occurs (which don't have to be related to JavaScript-exposed .stack strings).

from the proposal's README makes me wonder how this would be implemented in hosts such as Node.js, and what that implementation would mean on whether stack trace information would really be hidden from applications' code.

I would think that any JS VM facility that the Node.js runtime would rely on to log errors' "hidden" stack frames would need to be available/enabled by default, since this is a capability that Node.js developers expect to be enabled without having to run any dev tool that is not enabled by default.

Since any JS VM facility available to Node.js' internals is available to any binary add-on, they would be available to any application's code.

Am I missing something?

michaelficarra commented 4 years ago

Binary add-ons operate in a privileged context. They will have access to any information that is made available by Node.js. This proposal does not require that to be changed.

ghermeto commented 4 years ago

@michaelficarra can we add this to the spec text to be very clear what is considered privileged context and what isn't?

Would also be possible to add an example on how to access the stack frames using native module?

michaelficarra commented 4 years ago

@ghermeto I do not think it is appropriate for this to appear in the spec text. Hosts are allowed to do anything that is not explicitly restricted within the spec. As long as the spec text does not overbroadly word the restriction on appearance of stack frames, then the hosts have this implicit permission. I urge you to review the spec text in https://github.com/tc39/ecma262/pull/1739 to see if you think the wording is overbroad.

ghermeto commented 4 years ago

ok, I agree with that... The spec text might not be the right place for it. Maybe the README? I don't want this information to live only on a closed issue.

michaelficarra commented 4 years ago

@ghermeto Do you have a specific suggestion for a change to How does this affect devtools or other methods of inspecting a function's implementation details?? Why don't you just send a PR with what you think needs to be added?

Also, what exactly are you afraid of? Engine implementers are already very aware of their right to do anything that is not explicitly restricted by the spec. Additional text in the README is not going to do anything to help that.

ghermeto commented 4 years ago

I will send a PR