Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

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

Closed
domenic opened this Issue · 2 comments

2 participants

@domenic
Collaborator

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.

@domenic domenic was assigned
@kriskowal
Owner

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

@domenic
Collaborator

#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 domenic referenced this issue from a commit
@ef4 ef4 Don't mangle stack traces when an exception is seen twice.
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.
c2c7353
@domenic domenic closed this in 61567b7
@dfilatov dfilatov referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@dfilatov dfilatov referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.