Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Behavior when object is an error instances #2

Open
mhofman opened this issue Dec 3, 2024 · 2 comments
Open

Behavior when object is an error instances #2

mhofman opened this issue Dec 3, 2024 · 2 comments

Comments

@mhofman
Copy link
Member

mhofman commented Dec 3, 2024

What should the behavior of Error.captureStackTrace be when the object provided is an object with an [[ErrorData]] slot?

My preference right now would be to reset the internal error stack info, but not add a new private field or own stack property (this is partially assuming that we standardize a prototype stack property for Errors in https://github.com/tc39/proposal-error-stacks)

@mgaudet
Copy link
Collaborator

mgaudet commented Dec 6, 2024

I think my current implementation simply does [[Define]] a new property -- my current implementation doesn't do anything special with the [[ErrorData]] slot.

  • As a result you'll get a string valued own property "stack" on the provided object with the truncated stack string.
  • Using the prototype getter you could still get the un-truncated stack (and if we have code in let's say devtools that explicitly manipulates [[ErrorData]] (no idea if we do) they would ignore the own property. d

For the SES purposes, since both Error.prototype.stack and Error.captureStack trace are deniable, I think this is fine behaviour.

@mhofman
Copy link
Member Author

mhofman commented Dec 6, 2024

Yeah it might be fine for a data property. Just slightly worried about the consistency of stacks depending on how you consume them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants