Skip to content

Commit ff8ef81

Browse files
authored
Make error boundary doc more in style with the post (#213)
* Make error boundary doc more in style with the post * Update error-boundaries.md * Update error-boundaries.md
1 parent dfdddfd commit ff8ef81

File tree

1 file changed

+19
-12
lines changed

1 file changed

+19
-12
lines changed

content/docs/error-boundaries.md

Lines changed: 19 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -15,10 +15,12 @@ Error boundaries are React components that **catch JavaScript errors anywhere in
1515

1616
> Note
1717
>
18-
> Error boundaries do **NOT** work in the following scenarios:
19-
> * Event Handlers (See below ["How About Try / Catch"](#how-about-trycatch) for details about dealing with errors in event handlers)
18+
> Error boundaries do **not** catch errors for:
19+
>
20+
> * Event handlers ([learn more](#how-about-event-handlers))
2021
> * Asynchronous code (e.g. `setTimeout` or `requestAnimationFrame` callbacks)
21-
> * Server Side Rendering
22+
> * Server side rendering
23+
> * Errors thrown in the error boundary itself (rather than its children)
2224
2325
A class component becomes an error boundary if it defines a new lifecycle method called `componentDidCatch(error, info)`:
2426

@@ -136,37 +138,42 @@ However, React components are declarative and specify *what* should be rendered:
136138

137139
Error boundaries preserve the declarative nature of React, and behave as you would expect. For example, even if an error occurs in a `componentDidUpdate` hook caused by a `setState` somewhere deep in the tree, it will still correctly propagate to the closest error boundary.
138140

139-
However, an event handler inside of a React component could leverage `try` / `catch` to deal with errors that occur during event handling.
141+
## How About Event Handlers?
142+
143+
Error boundaries **do not** catch errors inside event handlers.
144+
145+
React doesn't need error boundaries to recover from errors in event handlers. Unlike the render method and lifecycle hooks, the event handlers don't happen during rendering. So if they throw, React still knows what to display on the screen.
146+
147+
If you need to catch an error inside event handler, use the regular JavaScript `try` / `catch` statement:
140148

141149
```js{8-12,16-19}
142150
class MyComponent extends React.Component {
143151
constructor(props) {
144152
super(props);
145-
this.state = { error: null }
153+
this.state = { error: null };
146154
}
147155
148156
handleClick = () => {
149157
try {
150-
// event handling that could possibly produces an error
151-
} catch(error) {
152-
this.setState({ error })
158+
// Do something that could throw
159+
} catch (error) {
160+
this.setState({ error });
153161
}
154162
}
155163
156164
render() {
157165
if (this.state.error) {
158-
// render a fallback UI
159-
return <h1>The Click Handler Produces an Error</h1>
166+
return <h1>Caught an error.</h1>
160167
}
161-
// ...
162168
return <div onClick={this.handleClick}>Click Me</div>
163169
}
164170
}
165171
```
166172

173+
Note that the above example is demonstrating regular JavaScript behavior and doesn't use error boundaries.
167174

168175
## Naming Changes from React 15
169176

170177
React 15 included a very limited support for error boundaries under a different method name: `unstable_handleError`. This method no longer works, and you will need to change it to `componentDidCatch` in your code starting from the first 16 beta release.
171178

172-
For this change, we’ve provided a [codemod](https://github.com/reactjs/react-codemod#error-boundaries) to automatically migrate your code.
179+
For this change, we’ve provided a [codemod](https://github.com/reactjs/react-codemod#error-boundaries) to automatically migrate your code.

0 commit comments

Comments
 (0)