3 ms·

This is not very useful because it only allows for error handling based on JS exceptions, which is rarely used (and in fact shouldn't be) for user defined error

This is not very useful because it only allows for error handling based on JS exceptions, which is rarely used (and in fact shouldn't be) for user defined error states. It also won't work with Promises, generators, async functions, etc. unless you setState({hasError: true}) on your error boundary differently than with componentDidCatch(). I'm not sure how this is useful in dev time, or how this is useful in productions. Throw when input invalid?

tedeh 9y ago
I suppose that it's not meant to deal with errors normal to the use of the application (like not entering an email in an input) but rather to exceptions and JavaScript errors. I'm imagining stuff like receiving data of an unexpected format from the server, which might break your application in unexpected ways (i.e. put it in an undefined state that is hard to reason about and would make it better to just "show a generic error").
danabramov 9y ago
This is not meant for user errors. This feature is for gracefully recovering from JavaScript errors that occur in production as a result of programmer mistakes. For example, Facebook heavily uses error boundaries in ads code. Even if one widget fails rendering, it doesn’t take down the entire page. You’re going to have some runtime errors if you use JavaScript, but this feature ensures you can gracefully recover from them (instead of just breaking the whole app as React 15 and earlier did). There are two other effects of this change: * React no longer has its own cryptic errors (because it doesn’t get “confused” when user code throws, and can cleanly fail fast if there is no error boundary). * Errors reported to the boundaries have a component stack trace attached to that, so you can know where exactly in the hierarchy the failure occurred. This can be pretty useful when debugging. I hope this helps!

tedeh 9y ago

I suppose that it's not meant to deal with errors normal to the use of the application (like not entering an email in an input) but rather to exceptions and JavaScript errors. I'm imagining stuff like receiving data of an unexpected format from the server, which might break your application in unexpected ways (i.e. put it in an undefined state that is hard to reason about and would make it better to just "show a generic error").

danabramov 9y ago

This is not meant for user errors. This feature is for gracefully recovering from JavaScript errors that occur in production as a result of programmer mistakes. For example, Facebook heavily uses error boundaries in ads code. Even if one widget fails rendering, it doesn’t take down the entire page. You’re going to have some runtime errors if you use JavaScript, but this feature ensures you can gracefully recover from them (instead of just breaking the whole app as React 15 and earlier did). There are two other effects of this change: * React no longer has its own cryptic errors (because it doesn’t get “confused” when user code throws, and can cleanly fail fast if there is no error boundary). * Errors reported to the boundaries have a component stack trace attached to that, so you can know where exactly in the hierarchy the failure occurred. This can be pretty useful when debugging. I hope this helps!