Skip to content

Make it clearer in error overlay when error boundary has caught an error #3627

Closed

Description

@selbekk

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

  1. node -v: 8.9.2

  2. npm -v: 5.5.1

  3. yarn --version (if you use Yarn): 0.17.10

  4. npm ls react-scripts (if you haven’t ejected): 1.0.0

  5. Operating system: Linux

  6. Browser and version (if relevant): Chrome 63

Steps to Reproduce

  1. bootstrap app with create-react-app
  2. create an error boundary
  3. 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

https://codesandbox.io/s/jvrwr388wv

Activity

  1. gaearon commented on Dec 19, 2017

    @gaearon
    Contributor

    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.

  2. selbekk commented on Dec 19, 2017

    @selbekk
    ContributorAuthor

    Ah alright, thanks :) It had me wondering what was happening, since the error boundary UI was shown at first, before it was hidden again.

    Could it be an idea to somehow indicate that the error was dealt with in an error boundary in the UI of the error overlay?

  3. gaearon commented on Dec 19, 2017

    @gaearon
    Contributor

    before it was hidden again.

    I wouldn’t expect your custom boundary to get hidden though. (Error overlay doesn’t do anything to dismiss it.)

    Could it be an idea to somehow indicate that the error was dealt with in an error boundary in the UI of the error overlay?

    I think this would be reasonable. Not sure how to do it though.

  4. selbekk commented on Dec 19, 2017

    @selbekk
    ContributorAuthor

    I wouldn’t expect your custom boundary to get hidden though. (Error overlay doesn’t do anything to dismiss it.)

    It's not dismissed, it's simply hidden behind the overlay (you can reproduce it in the codesandbox-demo above). If you remove the overlay from the DOM manually, you can see that my ErrorBoundary component renders as usual. Perhaps some bad choice of words on my part :)

    I think this would be reasonable. Not sure how to do it though.

    As far as I can tell, React tells us that it will try to recreate the component tree in the error message:

    React will try to recreate this component tree from scratch using the 
    error boundary you provided, ErrorBoundary.
    

    You can see it in action if you pop open the console in my codesandbox example.

    Perhaps we can check whether the error includes parts of this text - and if so, show some indication in the error-overlay UI?

  5. gaearon commented on Dec 19, 2017

    @gaearon
    Contributor

    Fair enough. I'll rename this issue to keep track of this.

  6. changed the title [-]Error overlay shown when error is caught with componentDidCatch[/-] [+]Make it clearer in error overlay when error boundary has caught an error[/+] on Dec 19, 2017
  7. SylarRuby commented on Jan 20, 2018

    @SylarRuby

    🙈 Never even see the "x" to close the overlay and to know this wont show in production is music to my ears. Thanks

  8. philraj commented on Jan 22, 2018

    @philraj

    I didn't notice the X to close the error overlay at first either. It might help to add a label like X Close. Though this is somewhat off-topic and might be better mentioned in a different issue.

  9. Timer commented on Jan 23, 2018

    @Timer
    Contributor

    There's a message at the bottom that says only visible in development (right?).

  10. gaearon commented on Jan 23, 2018

    @gaearon
    Contributor

    We might actually want to amend that wording to link to error boundary documentation. Since that's the thing that will show up in production instead.

  11. Timer commented on Jan 23, 2018

    @Timer
    Contributor

    We could also amend the message to say "press [escape] to close or X in upper right" or similar.

  12. iMerica commented on Jan 31, 2018

    @iMerica

    How do we actually test our error boundaries locally when using Create React App? Can we disable the full page debug iframe?

  13. selbekk commented on Jan 31, 2018

    @selbekk
    ContributorAuthor

    You can close the overlay with Escape or by pressing the x in the corner @iMerica 😊

  14. iMerica commented on Jan 31, 2018

    @iMerica

    Thanks @selbekk 👍

  15. Jakhotiya commented on Feb 3, 2018

    @Jakhotiya

    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?

  16. sag1v commented on Mar 19, 2018

    @sag1v
    Contributor

    On some cases you can't even hide the overlay (not using create-react-app). Well you can via the dev tools and manually delete the node but then you won't see the alternative component that the boundary should render.

  17. javierfernandes commented on Mar 23, 2018

    @javierfernandes

    @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 !

  18. raix commented on Mar 29, 2018

    @raix
    Contributor

    @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.

  19. rivertam commented on Apr 5, 2018

    @rivertam

    I definitely understand why it's not best practice to use error boundaries for control flow. My usecase is that I'm using a complex third party component for a debugging tool on the back side of my application. This third party component keeps throwing errors, which I believe is a bug of the third party component. Honestly, I'm not even sure. I'm basically just throwing together a quick prototype, and I want to fall back to a reasonable behavior when the component fails. By encouraging me to go with best practice here, you're basically telling me I need to either abandon this convenient component, fix the convenient component, or come up with an even hackier workaround.

  20. rojasmi1 commented on Aug 8, 2018

    @rojasmi1

    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.

  21. stale commented on Nov 2, 2018

    @stale

    This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 7 days if no further activity occurs.

  22. locked and limited conversation to collaborators on Jan 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions