Mark S. Miller
Mark S. Miller
Sounds good to me
Why not follow the proposed approach of a configurable `Error.prototype.stack` accessor property, as Mozilla does? As a configurable property on the prototype, it is both deletable and replaceable, enabling the...
> Migrating to accessors on the prototype seems infeasible for this. See the old code at https://github.com/tvcutsem/es-lab/blob/erroraccessor/src/ses/debug.js which I'd start with to shim the error stacks proposal. I just added...
https://bugs.chromium.org/p/v8/issues/detail?id=9386 reports a serious bug with the current v8 implementation. Comment 3 at https://bugs.chromium.org/p/v8/issues/detail?id=9386#c3 suggests moving towards this proposal would also help in fixing this bug.
No it is not. If it is on the prototype, it can be replaced before other code starts running. If it is an own property, since anything can provoke an...
FF and XS both have an accessor on the prototype. We propose here an accessor on the prototype. We make use of this on FF and XS, and we propose...
Good. SES already replaces Error and the Error API. Will try it out and see how safe it seems.
See https://github.com/endojs/endo/blob/master/packages/ses/error-codes/SES_UNEXPECTED_ERROR_OWN_STACK_ACCESSOR.md
Sounds good to me.
@lars-t-hansen I don't understand how any of this protects the JavaScript programmer in general. The FF fat pointers are at the C++ level and the w3 bug is webidl specific,...