Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add "unhandledException" event #566

Merged
merged 4 commits into from
Apr 26, 2024

Conversation

kettanaito
Copy link
Member

@kettanaito kettanaito commented Apr 26, 2024

Changes

Adds a new event to the HTTP events map called unhandledException. If the listener for that event is provided, whenever an unhandled exception occurs in the request listener, the unhandledException listener will be called (if present).

This allows the client to opt-out from the default handling of exceptions (producing 500 error responses), as well as do so conditionally. If the unhandledException listener does nothing, the default handling kicks in.

Note: The unhandledException listener receives a readonly request instance (non-interactive request). To affect the request, it receives an additional controller object with methods .respondWith() and .errorWith().

request.respondWith() operates on a promise basis and by the time exception occurs, that promise has been awaited already. Besides, I very much wish to move away from patching the Request instance with .respondWith() to the designated controller argument for the request listener as well. I see this as an incremental change in that direction.

interceptor.on('unhandledException', ({ error, request, requestId, controller }) => {
  controller.respondWith(new Response('fallback response'))
  // controller.errorWith(new Error('fallback error'))
})

request: interactiveRequest,
requestId,
})
const responsePromise = new DeferredPromise<Response>()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had to rewrite the Fetch interceptor to return a deferred Promise so we can expose functions like respondWith() and errorWith() to asynchronous contexts (the unhandledException listener). The listener cannot "return" anything to the pending Fetch promise, so instead it controls the deferred promise, which is always returned.

@kettanaito kettanaito marked this pull request as ready for review April 26, 2024 10:59
@kettanaito kettanaito merged commit a3afcf1 into main Apr 26, 2024
2 checks passed
@kettanaito kettanaito deleted the fix/opt-out-from-error-handling branch April 26, 2024 11:05
@kettanaito
Copy link
Member Author

Released: v0.29.0 🎉

This has been released in v0.29.0!

Make sure to always update to the latest version (npm i @mswjs/interceptors@latest) to get the newest features and bug fixes.


Predictable release automation by @ossjs/release.

@mikicho
Copy link
Contributor

mikicho commented Apr 28, 2024

This is really nice! thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants