Skip to content
This repository has been archived by the owner on Jan 22, 2025. It is now read-only.

Consider parsing stack strings instead of using Error.prepareStackTrace #117

Closed
domenic opened this issue Sep 26, 2012 · 2 comments
Closed
Assignees
Milestone

Comments

@domenic
Copy link
Collaborator

domenic commented Sep 26, 2012

Currently accessing an error's stack at all---even to log it---makes it unsuitable for Q's rewriter, since it is reified and thus Error.prepareStackTrace is never called.

If we manipulated and parsed the strings directly, instead of using Error.prepareStackTrace to grab and format the stack frames, this hazard would be avoided. Additionally, we would then work in Internet Explorer 10, since they have adopted the V8 stack trace format.

@kriskowal
Copy link
Owner

@domenic I’ll leave it to you to decide whether to merge #121.

@domenic
Copy link
Collaborator Author

domenic commented Oct 11, 2012

#121 is probably worth merging as a stopgap before I do more extensive stack trace-related work, but I need to get Q.onerror working first as a revision of #94. Will work on it tonight.

domenic pushed a commit that referenced this issue Oct 14, 2012
It's possible for the same exception to hit two different `end()` points, causing it to pass through the stack trace formatter twice.

On the second pass, `error.stack` is already a string, and the formatter mangles it by inserting newlines after every character.

Fixes #121 and #116. Related: #117.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants