create-react-app: Make it clearer in error overlay when error boundary has caught an error
Is this a bug report?
Yes
Can you also reproduce the problem with npm 4.x?
Yes
Which terms did you search for in User Guide?
componentDidCatch, error boundaries
Environment
-
node -v: 8.9.2 -
npm -v: 5.5.1 -
yarn --version(if you use Yarn): 0.17.10 -
npm ls react-scripts(if you haven’t ejected): 1.0.0 -
Operating system: Linux
-
Browser and version (if relevant): Chrome 63
Steps to Reproduce
- bootstrap app with create-react-app
- create an error boundary
- trigger an error in a child of that error boundary
Expected Behavior
I would assume React dealt with the error, and no overlay was necessary.
Actual Behavior
The error overlay is placed on top of the app, like an uncaught error occurred. If I manually remove the error overlay from the DOM (via devtools), the correct UI is rendered below.
Reproducible Demo
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 7
- Comments: 20 (11 by maintainers)
This issue is a Gotcha for people who are new to ErrorBoundaries and are just trying out the concept with create-react-app or on sandbox.io. You end up debugging for an hour before you realize that react-error-overlay is just hiding the boundary and boundary actually worked. @gaearon I would like to work on this issue. How can I help? How would you like to fix it?
How do we actually test our error boundaries locally when using Create React App? Can we disable the full page debug iframe?
@Jakhotiya not 1, but like 4hrs in my case.
I think that this is inconsistent. Is like a VM generating error messages for exceptions being try/catched just in case you swallow them. If I wrote an error boundary then I’m a grown up and I should be telling react/CRA: “let ME handle the errors”. If you wrote an error boundary and you are swallowing errors, then that’s your problem man 😃. No language or framework will protect you from bad error handling 😃
Disabling the overlay is not an option because I do want it for others “real uncaught” errors. As it is right now, it will probably end up confusing like those bad linter error that one end up saying “oh… that’s ok, that’s not an error”, and eventually one ignores a real error.
I suggest at least it should detect and inform that the error was caught by an error boundary. A really big feedback note there 😃 And/or to mention it in the docs (?)
Thanks !
Had exactly the same problem.
I totally agree on showing the error in development, but the small/grey letters at the bottom are far from visible and the documentation doesn’t clearly states that the overlay will still be displayed in development mode and can be dismissed. It’d be nice to have that documented and make the message at the bottom pop out a bit more.
You can close the overlay with Escape or by pressing the x in the corner @iMerica 😊
This is intentional. An unexpected error is still an error. (We don’t recommend using error boundaries for expected errors or control flow.)
Error boundaries are primarily useful for production, but in development we want to make errors as highly visible as possible.
@gaearon I didn’t know that we were limited to only throw errors?
imho I don’t mind the extra error in console when in development - but the screen overlay for “already handled” errors etc. is annoying.
We could also amend the message to say “press [escape] to close or X in upper right” or similar.
There’s a message at the bottom that says only visible in development (right?).
Fair enough. I’ll rename this issue to keep track of this.