-
Notifications
You must be signed in to change notification settings - Fork 16
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
TypeError: Line Number must be a Number #11
Comments
I would assume this is related to the use of |
Thank you for the awesome bug report, @gaearon. I'd prefer that we fix error-stack-parser to parse these lines correctly because I'd rather not allow users to have totally bogus line numbers. I'll take a look and see what can be done here. |
This was referenced Apr 28, 2016
Any progress on this? I'm running into this issue as well. |
@webular Would you like to look into fixing it? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi! We are using this library as a dependency of redbox-react via error-stack-parser, and I noticed there’s a kind of Chome Error object that causes it to crash.
I started filing this in https://github.com/stacktracejs/stacktrace.js by mistake so here goes a nice template 😄 .
Expected Behavior
Given an error object with the following stack as reported by
error.stack.toString()
:It should parse all lines correctly and should not crash.
Current Behavior
It crashes with
TypeError: Line Number must be a Number
while handling this particular line:As you can see, it has multiple entries separated by comma—presumably because the error was caught and rethrown, although I haven’t looked at why closely. The first item doesn’t have the line number info for some reason, but
stacktrace.js
assumes that it is always there. This makes it parse the location info incorrectly and throw later:## Steps to Reproduce (for bugs)
This is a very tricky one because I’m debugging a dev version of the project which involves compiling several libraries. If you trust me I’m not making this up, you can parse the stack string I documented above to reproduce the issue. 😄
Context
I noticed this working on React Hot Loader 3 that will rely on error boundaries in React to handle errors as you edit the code, fix them without reloading the app.
I noticed that in some cases the error box failed to appear, and tracked it down to this dependency.
Your Environment
Possible Solution
Be more resilient to parsing errors and check the line number for being a number during parsing, use
0
otherwise.The text was updated successfully, but these errors were encountered: