-
-
Notifications
You must be signed in to change notification settings - Fork 205
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
Most exceptions are logged as System.AggregateException #270
Comments
Although some of .NET's API will wrap exceptions in With that in mind, it was a design idea to not throw this information away automatically but perhaps shortsighted as for many usages of the TPL like yours this is likely noise only. It's a fair request to add the possibility to drop Another option is to add an opt-in: Code doing all that is here: sentry-dotnet/src/Sentry/Internal/MainExceptionProcessor.cs Lines 65 to 102 in c777366
In case you or someone else in the community like to help with a PR proposing a change. I'd be happy to review and discuss it further. Until then: The work around you're looking for would look like this: private class NoAggregateExceptionSentryEventProcessor : ISentryEventProcessor
{
public SentryEvent Process(SentryEvent @event)
{
@event.SentryExceptions = @event.SentryExceptions
.Where(e => e.Type != typeof(AggregateException).FullName).ToList();
return @event;
}
} |
I think a good solution here would be to automatically flatten aggregate exceptions when captured at system boundaries (i.e. via ASP.NET Core middlware, UnhandledExceptionHandler, or whatever) but not when captured directly using |
We should tackle this on 3.0 since we're adding arg names it'll affect grouping. Lets flatten in in the |
@bruno-garcia I'm trying to understand the code in sentry-dotnet/src/Sentry/Internal/MainExceptionProcessor.cs Lines 59 to 72 in bfb18ac
|
The problem is that below it returns the exception itself regardless: sentry-dotnet/src/Sentry/Internal/MainExceptionProcessor.cs Lines 74 to 81 in bfb18ac
|
So the goal is to drop |
@Tyrrrz I believe this is what most folks expect. Would be nice to have a switch to go back to the old behavior. |
@bruno-garcia - let's chat about this. Thanks. |
To summarize, we would like to add a client-side option to the SDK that will filter out aggregate exceptions, but would still keep all the inner exceptions. |
Running with .NET 4.7.2, with heavy use of
Parallel.ForEach
. After moving to sentry-dotnet from Raven, most of our exceptions now show up in Sentry dashboard as "System.AggregateException: One or more errors occurred.". Raven used to unpack those if there was just a single inner exception, which made the dashboard a lot more "glanceable".Now I understand this might be an explicit design choice not to unpack them: in this case, could you please provide a code sample how to preprocess them in the client code (I'm guessing somewhere with filters?)
The text was updated successfully, but these errors were encountered: