> For the complete documentation index, see [llms.txt](https://tech.x2bee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tech.x2bee.com/dev-guide/developer-guide-en/pjt-prepare/publish-your-docs/store-front-framework-next.js/02.-coding-guide-and-essential-packages/5.-error-handling.md).
# 5. Error Handling
This document explains error handling. It focuses in particular on error handling in JavaScript server actions and 404 error handling in nested routes.
***
## Add try/catch to Server Actions
First, add JavaScript's try/catch statement to the server actions so that errors can be handled appropriately.
You can spend a few minutes updating the server actions, or copy the code below.
{% stepper %}
{% step %}
### Create Invoice (createInvoice)
{% code title="/app/lib/actions.ts — createInvoice" %}
```
```
{% endcode %}
{% endstep %}
{% step %}
### Update Invoice (updateInvoice)
{% code title="/app/lib/actions.ts — updateInvoice" %}
```
```
{% endcode %}
{% endstep %}
{% step %}
### Delete Invoice (deleteInvoice)
{% code title="/app/lib/actions.ts — deleteInvoice" %}
```
```
{% endcode %}
{% endstep %}
{% endstepper %}
If you force an error in a server action, it behaves as follows:
{% code title="/app/lib/actions.ts — deleteInvoice (throwing error example)" %}
```
```
{% endcode %}
Now, if an error occurs in a server action, the error will be shown on localhost. During development, checking these errors lets you catch potential issues early, and you can provide the user with an appropriate error message to help keep the application running.
{% hint style="info" %}
When returning an error from a server action, be careful not to include sensitive information in the message exposed to the user. It's also useful in production to send the error to a logging/error reporting tool so it can be tracked.
{% endhint %}
## Nested Routes
Errors propagate to the nearest parent error boundary. Therefore, a parent segment that has an error.tsx file can handle errors from nested child segments. However, an error boundary does not handle errors that occur in layout.js within the same segment (because the error boundary is nested inside that layout component).
### Handling All Errors with error.tsx
The error.tsx file is used to define a UI boundary for a route segment. It acts as a catch-all for unexpected errors and can display a fallback UI to the user.
{% code title="error.tsx" %}
```
```
{% endcode %}
Example: If you create an error.tsx file like the one above and trigger an error, the fallback UI will be shown to the user.
### Handling 404 Errors with the notFound Function
The notFound function is useful when you try to fetch a resource that doesn't exist. error.tsx is useful for catching all errors, but use notFound when you want to handle a missing resource (404) more specifically.
{% code title="/dashboard/invoices/\[id]/edit/page.tsx" %}
```
```
{% endcode %}
In the example above, if there is no invoice value, it navigates to the notFound page.
Below is an example of the not-found component for that route.
{% code title="/dashboard/invoices/\[id]/edit/not-found.tsx" %}
```
```
{% endcode %}
Handling a 404 with notFound displays the following UI.
notFound takes precedence over error.tsx, so use it when you need more specific 404 handling.
If you want to handle a not-found case for the entire application when there is no matching route, you can apply a notFound call to a catch-all segment such as \[...not\_found], so that when a requested page does not exist, notFound handling is applied.
.png?alt=media&token=bfbdd54b-2922-4617-a016-1d3f645f87e2)
.png?alt=media&token=b81f739c-6fa0-4fc8-bd79-f16969413c17)
.png?alt=media&token=fa5a78d9-99f1-42ff-a1e1-4ddf3c132c45)
.png?alt=media&token=f3138f30-8098-43df-abb4-13ebb9e4ba3b)