-
Notifications
You must be signed in to change notification settings - Fork 2.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
Refactor DOMException handling code to avoid redundant exceptions generation #724
Comments
This really becomes counterproductive when |
Would be great if this issue could be taken into consideration! |
@andrekovac exactly. I've got so many dependencies, none of them causing anything like this. It's only fetch, and causing whole (already-slow) debugger to step everytime I restart my RN app, and no one is even willing to fix it. I think I'll just switch to something else like axios if none of my dependencies explicitly depend on fetch. |
@canpoyrazoglu, you yourself are not willing to fix this. This is an open source project worked on by people in their spare time. You can just as easily fix the issue yourself. |
… and catching the exception which may get thrown fixes #724
That took 3 minutes to fix. #797 |
… and catching the exception which may get thrown fixes #724
… and catching the exception which may get thrown fixes JakeChampion/fetch#724
Hello, we are the development team of VS Code extension for debugging React Native apps (vscode-react-native).
whatwg-fetch
package is used in React Native lib. In our extension we debug React Native apps as a Node.js processes. Node JS global context doesn't containDOM
modules, so"exports.DOMException is not a constructor"
exception is generated inwhatwg-fetch
package if fetch function is used in a React Native project.Could it be better to firstly verify if there is
DOMException
module in environment global context and only after that use try/catch construction? IfDOMException
module doesn’t exist it can be better to create this module without exception generation.Here is the issue for the corresponding case in the debugger extension repository.
The text was updated successfully, but these errors were encountered: