Handling server errors

[dchenk]

Using the server script example (https://github.com/frandiox/vite-ssr/blob/master/examples/node-server/index.js), whenever a runtime error occurs and an exception is thrown, the server crashes.

How do people:

1. catch the error at the global level to allow the server to stay up as if the error is scoped to the request?
2. render an error page after the error is caught?

[frandiox]

Ideally you catch the error as soon as it happens by wrapping your data-fetching logic, APIs, etc. in try/catch. Then, in case it's the Vue/React rendering what fails for any unhandled error, wrap the await renderPage(url, { ... }) also in a try/catch.
This error should be quite uncommon since it means there's an issue in the app itself or similar. In the catch you can either:

• Return a hardcoded HTML (perhaps injecting the error message).
• Redirect to a static file that shows a generic error page.
• Use renderPage again but change the URL to a simpler error route (a route where you are rather certain this error won't happen again). -- I'm not sure if this would have a problem during hydration though 🤔

[dchenk]

Thanks for your response. After posting this question I implemented the third option you listed to see if it could work. It sort of works in that the SSR output is the error page as expected, but when the client then hydrates/renders, everything is replaced with what's rendered by the client and the error message component is not shown. I guess this makes sense though.

It feels like an actual redirect to an error page is unsatisfactory UX... it might feel jarring to the user to end up on some URL path completely different from what they requested. But this wouldn't be too hard to implement and, as far as I can tell, should work.

Depending on how the first method you listed is implemented, it may result in the same behavior that I'm seeing with the third method. But I should think some more about a creative way one could do this so that: (1) the SSR-generated HTML isn't immediately replaced by the client; (2) the URL pathname is what the user requested; and (3) routing still works.