-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Output error description on analysis errors #84
Conversation
'error' object is something like 'RangeError', it doesn't have any 'properties' in JSON sense and will yield a "{}" string. But it do have toString() method, so casting it to string will produce a meaningful error description.
This code path is taken when an unexpected exception is thrown. We can't make any assumptions about the exception type because it's unexpected. It might be a stack overflow, a dereference of an undefined variable, etc. For that reason, I don't think we can make the assumption you're making here. |
Out of curiosity, have you seen this code path taken? If so, I'd love to know about it so I can diagnose the underlying problem. |
Reasonable. Any way to detect that this is some internal exception like RangeError? Maybe parent class check? Seeing "{}" as an error result is sad for end-user. |
Not an actual problem. I'm testing LSP support in VSCode and generating large codebases for pyright to chew on. I saw this exception then my codebase includes more "calls" between files than Python allows (>140). BTW, "mypy" is ok with that. |
The error information should already include the stack crawl for the exception, which is typically more useful in diagnosing the error than any other information. You said "includes more calls between files than Python allows (>140)". Can you elaborate? What do you mean by "calls between files"? I wasn't aware of any intrinsic limits that Python places on the number of calls. |
Nope. It looks like this. No call stack, just "{}" in your version (or "RangeError: Maximum call stack size exceeded") with my adjustment:
Python function/method calls are stack-based and the language will throw "stack overflow" exception after ~140 consecutive calls (depends on version, architecture, memory etc). So the code i'm testing is not a valid Python code. Just a lot of files to put some pressure on a tool. |
In this case, the crash is due to infinite recursion in the pyright code, not in the Python code it's analyzing. So this is clearly a bug in pyright, and I'd like to get it fixed. Would you be willing to share your sample code that's causing it to occur? If not, perhaps you could explain at a high level what you're doing that exposes this bug? Thanks! |
Sounds reasonable. I created some code and reproduction steps for you: #85 What about "Error performing analysis: {}" output? Any ideas how this "{}" can be changed for something more user-friendly? Maybe, I can check exception object has "toString()" method and call it for text representation if available, instead of JSON.stringify()? |
I'm not so concerned about making this error user-friendly because it should never occur. :) It's a bug in the analyzer. |
'error' object is something like 'RangeError', it doesn't have any 'properties' in JSON sense and will yield a "{}" string. But it do have toString() method, so casting it to string will produce a meaningful error description.