Handle thrown errors

[mswjs]

Handle thrown errors

[kentcdodds]

I have some utilities I use in my resolvers. For these utilities it's just easier to throw an error (because we don't have access to the context):

throw new Error('username must be provided')

I realize that I'm missing the status code for this case and could probably make something work for that.

Also, there are sometimes regular runtime errors for things I haven't considered and it would be nice if the whole app didn't just crash when I hit those.

[kettanaito]

Released in 0.12.0.

Please refer to the guide of mocking server errors in case your goal is to mock an error. I believe that introduced error handling is primarily useful for handling unintended exceptions inside request handlers, so they don't crash the application they are being used in. Similar to how you compose an error response in Express, I'd recommend to do so using the library's res() function.

[kettanaito]

Makes sense. I'd treat such errors as 500, but without the X-Powered-By: "msw" header set to distinguish between mocked 500 response and library's error.

@kentcdodds, could you please describe what use case led to an error? That way I will make sure I account for all scenarios. Thanks.

[kettanaito]

That's reasonable, thanks for sharing.

I find the safest way of error handling in this case to be the mockServiceWorker.js itself. That brings up the question of how to ensure that the installed library operates with the last Service Worker file (#81). Since the Service Worker is served by the application, it's possible to have an old file served, while the client-side code expects a different behavior from it.

I'm going to tackle Service Worker's integrity firsts, and introduce internal error handling as the next step. Meanwhile, I suppose you can handle such errors by doing this:

const { start } = composeMocks(/* your request handlers */)
start.catch(console.error)

This will not take into account any exceptions raised by mockServiceWorker.js, but rather cover the errors in the client-side library.

[kentcdodds]

Hmmm.. But the error is thrown by the resolver which is called by the client-side code, not the service worker right? — Kent C. Dodds

--- original message --- On March 24, 2020, 3:28 PM MDT [email protected] wrote: That's reasonable, thanks for sharing. I find the safest way of error handling in this case to be the mockServiceWorker.js itself. That brings up the question of how to ensure that the installed library operates with the last Service Worker file (#81). Since the Service Worker is served by the application, it's possible to have an old file served, while the client-side code expects a different behavior from it. I'm going to tackle Service Worker's integrity firsts, and introduce internal error handling as the next step. Meanwhile, I suppose you can handle such errors by doing this: const { start } = composeMocks(/* your request handlers */) start.catch(console.error)

This will not take into account any exceptions raised by mockServiceWorker.js, but rather cover the errors in the client-side library.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. --- end of original message ---

[kettanaito]

@kentcdodds, that's correct. The call stack overview looks as follows:

SW -- respondWith(pending Promise, (1)) -> match req on client side -> get response (2) -> resolve Promise

The error occurring in the resolver is inside the call stack of the Service Worker's respondWith (1), if it's handled on the Service Worker side it would act as the top-level safeguard for all errors within that stack. Is this a wrong presumption? 🤔

[kentcdodds]

Oh, I see what you mean. Yes, that makes sense. I'm good with what you've suggested. Thanks! — Kent C. Dodds

…

--- original message --- On March 24, 2020, 3:50 PM MDT [email protected] wrote: @kettanaito, that's correct. The call stack overview looks as follows: SW -- respondWith(pending Promise, (1)) -> match req on client side -> get response (2) -> resolve Promise The error occurring in the resolver is inside the call stack of the Service Worker's respondWith (1), if it's handled on the Service Worker side it would act as the top-level safeguard for all errors within that stack. Is this a wrong presumption? 🤔 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe. --- end of original message ---