Error Boundaries: Gotta Catch ’Em All

In the last lesson, we saw how nested routing in Remix makes our web app faster and enhances the developer experience. With the help of nested layouts, it is easier to manage and maintain different sections of the app since each section can be encapsulated within its own layout. This modular approach enables us to build complex user interfaces while keeping the codebase clean and organized.

Another significant advantage of using nested routing in Remix is the implementation of route-level error boundaries. In software development, it is a given that no code is entirely free from bugs. However, the impact of these bugs on the user experience can be mitigated. Remix's route-level error boundaries offer a graceful error-handling mechanism. When an error arises in a specific app section, only that section is affected, keeping the rest of the application functional. This localized error handling is crucial as it ensures that a problem in one part of the app does not compromise the entire application, thus enhancing the overall robustness and user experience.

Remix is designed to automatically capture and manage errors, rendering the nearest error boundary for errors that occur. These errors might arise during component rendering or in loader or action functions and can occur on both the client and server sides. The errors handled can vary widely, from predictable ones like an invalid note ID to unpredictable runtime errors in the code or its dependencies. The error boundary in Remix is versatile and capable of addressing nearly all error types.

Let’s start with a very simple scenario. Let’s intentionally throw an error object from our loader instead of sending the expected response to simulate the error handling.

If we now visit an individual notes page, we will see that our app has crashed. We also receive a 500 Internal Server Error response status code in the network dev tools. This is not desirable from a user experience perspective.