Disable returnLastResortErrorResponse to allow the Express error handler to kick in

[haines]

(Migrated from remix-run/remix#9477)

In the react-router-express adapter, there's a catch that forwards errors to the next middleware in the stack:

react-router/packages/react-router-express/server.ts

Lines 67 to 71 in a11a013

	} catch (error: unknown) {
	// Express doesn't support async functions, so we have to pass along the
	// error manually using next().
	next(error);
	}

This is good, because I can register an error handler in my Express app to display a branded "server error" page.

However, returnLastResortErrorResponse means that errors in the request handler aren't thrown, so that catch isn't triggered and the Express error handler isn't called.

react-router/packages/react-router/lib/server-runtime/server.ts

Lines 741 to 755 in a11a013

	function returnLastResortErrorResponse(error: any, serverMode?: ServerMode) {
	let message = "Unexpected Server Error";
	if (serverMode !== ServerMode.Production) {
	message += `\n\n${String(error)}`;
	}
	// Good grief folks, get your act together 😂!
	return new Response(message, {
	status: 500,
	headers: {
	"Content-Type": "text/plain",
	},
	});
	}

I think it would be nice if the react-router-express disabled returnLastResortErrorResponse, causing the error to be thrown from the request handler and passed on to Express instead. The default Express error handler does pretty much exactly the same thing as returnLastResortErrorResponse anyway, so even in apps without a custom error handler this would be a reasonable behaviour (i.e. it would not have to be configurable externally).

[rossipedia]

I think I would personally prefer an opt-in behavior such as an onError option for createRequestHandler which would preserve existing behavior if omitted, but if present would bypass that "last resort" error Response and let devs decide what to do.

Incidentally, I also would love some kind of "pass-through" option like onNoMatch that would let you decide what to do if none of the routes in your ServerBuild matched the incoming request, instead of unconditionally showing an error boundary.