-
Notifications
You must be signed in to change notification settings - Fork 413
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
Handle thrown exceptions #272
Comments
Here's my attempt at creating an "error boundary" using the If used to wrap a root component as explained in the gist, the component gracefully handles exceptions thrown downstream in the component hierarchy. Let me know if that works for you. |
Would be great to have this improved in the next release. |
This came up on clojurians the other day. Timothy mentioned that when he tested this recently, Reagent (and React) was able to recover from exceptions thrown in the render functions. I also wasn't able to reproduce the original problem anymore (but didn't try too hard), even without the error boundary set. I tried to go through React's changlog to see if any recent changes could have fixed this but didn't find anything. Is it possible that somehow recently this problem has been solved, either on React's or Reagent's side? If the problem persists ("unable to read property of" or similar errors thrown after fixing an exception in a render method and rerendering), a minimal repro case would be very helpful. |
https://facebook.github.io/react/blog/2017/07/26/error-handling-in-react-16.html is the way this will be handled in React 16. It seems like it should be pretty easy to support in Reagent. |
Error boundaries are supported with |
React doesn't handle exceptions particularly gracefully out of the box. Exceptions thrown during rendering will bubble up and destroy all of the components up to the root, without calling lifecycle methods. facebook/react#2461 is an issue that tracks this.
This exception handling behaviour affects us in re-frame. If app code throws an exception while rendering, then the component is destroyed without calling component-will-unmount, and Reagent doesn't decrement the watch count on the reaction (re-frame subscription). Because the watch count is inaccurate, Reagent never calls the on-dispose, and the subscription stays in the re-frame cache, causing further issues.
It looks like if we provide
unstable_handleError
as a method on a Reagent component, then the initial mount is called in a try/catch. unstable_handleError is unstable, but this may be worth investigating, either now or later on when React marks it as stable.The text was updated successfully, but these errors were encountered: