You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 22, 2025. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
#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.
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.
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.The text was updated successfully, but these errors were encountered: