Throwing error in fetch causes server to stop

[amanketebo]

I've setup an endpoint that can sometimes throw an error in the fetch method and it seems to be stopping the server from running and on the client sides shows the error overlay.

Should we not be throwing errors from within the fetch method and catching errors in it instead, I'm probably missing something.

Endpoint and the part of my code that throws the error:

Error overlay that gets shown in the browser:

Error on the server:

[lilnasy]

You are currently expected to try-catch the client side call. I have some ideas for how errors should be handled natively, but I haven't settled on anything yet.

[lilnasy]

As for the server stopping, the server continues to be able to serve requests. What's happening is here is Astro's default behavior where server errors show up in the browser in dev mode.

[lilnasy]

If anyone is willing to suggest a simple to understand, type safe API for error handling, I'd be happy to implement it very soon!

My one strong opinion is that the server error trace should not be sent to the browser, unlike the case with tRPC. This likely means something like...

defineApiRoute({
    fetch() {},
    throwErrorToClient(errorThrownByFetchAbove) {}
})

...where it is explicit that some "non-happy" data should be sent to the browser.

[amanketebo]

Ah I see thanks for explaining that, and I should have shared this along with the other screenshots but here's the try catch I'm using but even through we're handling the error it still causes that overlay to show up which maybe is expected since like you said with Astro's default behavior the error shows up in the browser when in dev mode.

Do you know of a way to opt out of that default Astro behavior or at least make it so the error overlay can be exited out of since it basically stops anything further from being done on the page in dev mode.

(I'm coming from the iOS and Swift world so apologies if these are newb questions, but l'm getting more familiar web dev and loved the type safety this package and cleanness of the api this package offers so thank you for that!)

[lilnasy]

Yeah, it should be simple enough to workaround it for now. I could look into making API routes an exception within astro itself soon as well.

[lilnasy]

Workaround released in astro-typed-api@0.2.2. An API for sending error messages to the browser can be a new discussion.