-
-
Notifications
You must be signed in to change notification settings - Fork 26.8k
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
Unable to inspect variable defined in async/await catch statement #11093
Comments
Update: I was able to work around the issue by adding the following in the "browserlist": {
"development": [
"last 1 chrome version",
"last 1 firefox version",
"last 1 safari version"
]
} This disables the regenerator-runtime transformation in development, making debugging work as expected. This exists by default in new projects created with create-react-app, so for anyone who finds this issue because they are having a similar problem, make sure the above config info didn't get deleted from your package.json. Turns out that was the issue with the project I was working on. Someone accidentally combined the production and development settings into one option. |
Describe the bug
When debugging inside the catch block of an async/await
try...catch
block, I am unable to inspect the error object/value that is defined as part of thecatch
statement when the application is setup to support IE 11. Attempting to set a watch or to check the value of the error variable as assigned results in aReferenceError
. The error variable as defined does not appear in the local variable scope pane of my debugger either. I encountered this issue inside a react component, though it seems to apply anywhere async await calls are transformed by regenerator. See related issue in regenerator for more info. From my testing, the underlying cause of this issue seems to be the same as what I describe in the regenerator issue.Should the linked issue in regenerator be resolved, that would resolve this issue as well. Otherwise, I would suggest that regenerator only be applied during a production build and not a development build to prevent this from becoming an issue when debugging (especially since most any modern browser now supports generators and async/await) if the issue cannot be fixed with a code/sourcemap change. Predictable debugging is important for development instances. Perhaps making this a configurable setting in create-react-app could also suffice.
Did you try recovering your dependencies?
A recovery of dependencies did not change this behavior. This is occurring on a new project with NPM v7 used and with the project I initially found the issue in, which uses the following NPM info: (This project is keeping to NPM 6 due to compatibility issues we are having in my organization)
npm --version
: 6.14.6Which terms did you search for in User Guide?
async catch ReferenceError regenerator
Environment
Environment Info:
Steps to reproduce
(Write your steps here:)
error
variable or enter the variable name error in the debug console. Either a ReferenceError will occur or the variable will evaluate as undefined.Expected behavior
Expected to see the value of the
error
variable as defined in thecatch
statement in my debugger's console or watch window.Actual behavior
Breakpoint set:
Console Output (Chrome DevTools):
Variables Pane (Chrome DevTools):
Watch (Chrome DevTools and VSCode):
Chrome
VSCode
This same behavior occurs in both Chrome DevTools and VSCode (expected as VSCode connects to Chrome's debugger)
It appears that the error object can be referenced when debugging using
_context.t0
, though the ideal behavior would be to have the sourcemap translateerror
(catch statement variable) to_context.t0
Reproducible demo
This example uses Node 16.3 and NPM 7.15.1
https://github.com/Kytech/create-react-app-async-catch-debug-issue
All edits needed to cause this issue from a clean create react app setup are done in the second commit (minus the nvmrc file)
To reproduce issue, start the app using
npm run start
and follow the directions on the page once it loads (and in the comments of the App.js file)The text was updated successfully, but these errors were encountered: