You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Expecting onError handler allows me to choose which errors to capture? Here are our set up docs.
Actual Result
The onError handler always captures unhandled error events in Sentry, even when Sentry.captureException is never called, instead it gets captured by errorHandler.
Hello, we instrument the onError handler in hono automatically to capture all unhandled exceptions. So the docs are outdated here.
Hm...but now that I think of it: It's probably better to manually call captureException in the onError handler depending on when you want to capture something - either all or just the things you didn't handle.
We just had an internal discussion around that because the onError handler is instrumented on purpose (#16355).
To make it possible to still have room for decision around capturing an error or not we'll create a honoIntegration in the Cloudflare SDK which will add the option shouldHandleError (like in the Fastify SDK). This will only capture errors with specific status codes and messages.
By default, Sentry captures exceptions with error.status >= 500 || error.status <= 299.
That seems to indicate that by default, only thrown HTTPExceptions will be captured by Sentry…but what happens if another error is thrown ( that doesn't have a status)?
This seems important to document, as the nuances around this can result in thousands of unintended captured errors maxing out an error budget, as it did for us.
Ah that's a good catch. The documentation is indeed a bit misleading here as it should say "IF there is a status, if will capture ...." - I will update this.
Activity
linear commentedon Sep 20, 2025
JS-961 onError handler always captures unhandled error events
s1gr1d commentedon Sep 22, 2025
Hello, we instrument the
onErrorhandler in hono automatically to capture all unhandled exceptions.So the docs are outdated here.Hm...but now that I think of it: It's probably better to manually call
captureExceptionin theonErrorhandler depending on when you want to capture something - either all or just the things you didn't handle.s1gr1d commentedon Sep 22, 2025
We just had an internal discussion around that because the
onErrorhandler is instrumented on purpose (#16355).To make it possible to still have room for decision around capturing an error or not we'll create a
honoIntegrationin the Cloudflare SDK which will add the optionshouldHandleError(like in the Fastify SDK). This will only capture errors with specific status codes and messages.[-]onError handler always captures unhandled error events[/-][+]onError handler always captures unhandled error events (adding `honoInstrumentation`)[/+]cobyeastwood183 commentedon Sep 22, 2025
Thank you, this would be great!
feat(cloudflare): Add `honoIntegration` with error-filtering function (…
github-actions commentedon Sep 24, 2025
A PR closing this issue has just been released 🚀
This issue was referenced by PR #17743, which was included in the 10.15.0 release.
timkelty commentedon Sep 29, 2025
Thank for you adding this and updating the docs!
timkelty commentedon Oct 1, 2025
@s1gr1d I'm still unclear about one bit:
That seems to indicate that by default, only thrown
HTTPExceptions will be captured by Sentry…but what happens if another error is thrown ( that doesn't have astatus)?Looking at the code, it looks like it considers any
Erroreligible, and will default to capturing if the object doesn't have astatus.This seems important to document, as the nuances around this can result in thousands of unintended captured errors maxing out an error budget, as it did for us.
s1gr1d commentedon Oct 9, 2025
Ah that's a good catch. The documentation is indeed a bit misleading here as it should say "IF there is a status, if will capture ...." - I will update this.