Yet another React Error Boundaries explanation
Tags: react, webdev, javascript, errors
Published: 2019-10-13 18:49:47

---
title: Yet another React Error Boundaries explanation
published: true
description: How React Error Handling is supposed to work using Error Boundaries
cover_image: https://i.imgur.com/Ghixy4a.jpg
tags: react,webdev,javascript,errors
---

_This article is a kind of warm-up for the part 2 on how we can handle React Error Boundaries for better sync and async error handling using MobX._

### This time...
There comes __this__ time when you have to cater for your users and not let them be the real testers of your application.

That means making sure that the experience you are building is ready to handle the _unexpected_. The _unexpected_ for us software engineers/developers working on the web is most of the times
- some network request error
- an unreachable resource or 
- just a human mistake due to insufficient test coverage

In any of these cases we don't want our users to either see a blank screen or end up in an unresponsive state; this will result in one of the worst things in experience design, __confusion__. 

### React to the rescue
To combat some of these cases, React v.16 and above has us covered with the `componentDidCatch(error, info)` lifecycle method. Every Component implementing this method becomes what is called an __Error Boundary__. In my understanding, a wrapper Component that catches unhandled errors/exceptions that bubble up from its children.
_We won't get into too much detail on how this works and luckily for everyone using React, the core team has us covered in the [Error Boundary documentation](https://reactjs.org/blog/2017/07/26/error-handling-in-react-16.html)._

This though has created a bit of confusion around what errors can be handled by this component.
_Is it an all around handler for Application-level errors ?_
_Is it only for caught exceptions ?_
_Does it only applies on React Component implementation ?_

These and more questions by the community have raised some issues such as  
{% github https://github.com/facebook/react/issues/11334 %}

### Fiddling around with it
What I can infer (and is most probably what the real purpose of this implementation is about) is that the Error Boundaries are made to handle exactly errors that __technically__ _, as Dan Abramov states,_ happen inside any React lifecycle hook. That means code executed synchronously in these methods. No Promise rejections/exceptions, no callback errors, nor any asynchronous code as mentioned in the documentation.

For a simple example you can [check in this fiddle](https://jsfiddle.net/igneel64/eq6t1cLa/8/) that the `fetch` error gets thrown but the Error Boundary `componentDidCatchMethod` never gets called. I am reminding you that this is not technically code that runs in the React lifecycle methods, so it is not handled by the Error Boundary.

On the contrary if you enable
`this.setState(() => { throw err });`
you will see that this now is getting handled by the Parent successfully. This seemed kind of non-intuitive and smelly to me but it seems to work as stated at https://github.com/facebook/react/issues/13523.
![we need better error handling](https://hackernoon.com/hn-images/1*7ccuxKW-yUILVqqvpmBb-A.png)

### Next steps
In the event that you are trying to build a larger application than this fiddle, this can get pretty messy, pretty quickly. Also you probably want to be in more control of how you handle each type of error and trust me you do not want to fatten up any Error Boundary Component with business logic and cross-cutting concerns.
In our case I will be showing you in the next part how we used MobX to set up an initial sketch, along with some helpers, for our component sync and async error handling logic.

_P.S. If you haven't tried out MobX for state management, believe me you might be missing out on some state management pain alleviation._

_Cover Image by Aamir Mohd Khan from Pixabay_