-
-
Notifications
You must be signed in to change notification settings - Fork 441
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
Feature request: report suppressed exceptions #542
Comments
This seems like a good idea. At first glance I don't think we should add them to the main event stacktrace as that may be confusing and would affect issue grouping. I'm not even sure where in the existing exception chain they would be placed? So I see a few options and I'd love some feedback:
|
The main use-case for suppressed exceptions (if I'm not mistaken), is when you're processing some calls, that might produce a lot of errors, but you want to aggregate those errors and not kill the process itself. And at the end, you might want to throw a new exception, informing that part of the process failed and attach all the suppresed exceptions using
IMHO they can be considered "cause" of the main exception, but because you cannot have an array of causes, they're "suppressed".
"extra" makes sense as a temporary solution - because knowning about them is more important than having them printed nicely.
I don't have opinion on this
Yes, exactly! just like there is |
Yeah, adding a new section in Sentry will (AFAIK) be a much larger process. In the short term I can definitely add them to extra or breadcrumbs on the SDK side. Maybe with an option to enable/disable if people really care. I'll try to take a look at this soon, or as usual we're open to PRs. Thanks for the idea! |
We're running through the same problem. We're using project reactor with webflux and for some Timeout/Null Pointer Exceptions. We don't get any stack trace but supressed exception contains the detailed info of where the error originated. Currently I'm manually adding it as a breadcrumb. Please let me know if there are any out of the box solution to serve the purpose.
|
@vaibhavagnihotri you could create a chained exception instead of adding breadcrumbs, Sentry already supports chained exceptions thru the |
@marandaneto yes, but And you can have always only one |
yes, I meant, it's just a workaround, these exceptions would come thru and would be shown and have more info than just breadcrumbs. |
@marandaneto Some times cause remains null but suppressed exception contains the assembly trace from producer. Exception class - Exception.getMessage() - Exception.getCause() - Exception.getSuppressed()[0].getMessage() - |
I encountered this today as well. I think more users will be affected by this as they migrate away from RestTemplate to WebClient. |
@marandaneto do you have any suggestions on how suppressed exceptions should be attached to One idea is to add them to exception queue in |
yep, that's what I had on my mind too |
be aware that we need an abstraction for |
Since this will require a lot of code to abstract away what's needed to work around the lack of API on Android, we decided to add this to the core For reference, API 16 (which we require for NDK) to 19 isn't a huge jump in terms of Android devices covered and we might be able to do that not too far in the future. |
Until we are able to support suppressed exceptions in core, you can write custom
|
Hope to see this implemented. I somehow was under the impression that it was supported, until I noticed that it isn't. |
Fixed by #3396 |
All exceptions in
Throwable.getSuppressed()
should be reported and visible in Sentry.They might contain important information, that is not in the "main" exception.
Does Sentry itself have a mechanism for this? Or do they have to be reported separately?
The text was updated successfully, but these errors were encountered: