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

Expose EnumerateChainedExceptions #1733

Merged
merged 6 commits into from
Jun 23, 2022
Merged

Conversation

SimonCropp
Copy link
Contributor

No description provided.

/// Recursively enumerates all <see cref="AggregateException.InnerExceptions"/> and <see cref="Exception.InnerException"/>
/// Not for public use.
/// </summary>
public static IEnumerable<Exception> EnumerateChainedExceptions(this Exception exception, SentryOptions options)
Copy link
Member

Choose a reason for hiding this comment

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

This not being for public use but part of the global namespace don't go well together.
Should we remove the note on the xml doc?

Or perhaps this is best not being an extension method of Exception? If it's under a different namespace it will already help not show up on the user's intellisense. The goal is to share the built-in behavior with the Unity IL2CPP support

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm ok with it as is, since it includes a SentryOptions parameter - we're not likely to step on anyone. We can hide it from intellisense with EditorBrowsable

yield return inner;
}
}
return exception.EnumerateChainedExceptions(_options)
Copy link
Member

Choose a reason for hiding this comment

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

I was thinking we could refactor out this class to have a base class, so that the code that follows it doesn't need to iterate on the exceptions once again:

https://github.com/getsentry/sentry-unity/pull/683/files#diff-d7c6f55c576cbd905ba5affcc1c578fd120655cdfcdc520994c837efeeebccc2R33

Then a third time to have the original + the Sentry exception side by side:

https://github.com/getsentry/sentry-unity/pull/683/files#diff-d7c6f55c576cbd905ba5affcc1c578fd120655cdfcdc520994c837efeeebccc2R47

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bruno-garcia i dont really understand what you are proposing here. can we sync my tuesday morning?

Copy link
Member

Choose a reason for hiding this comment

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

I thought of re-thinking these hooks but didn't get that far, #1734

Copy link
Member

@bruno-garcia bruno-garcia left a comment

Choose a reason for hiding this comment

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

Unless @mattjohnsonpint disagrees, we can go ahead with this

Copy link
Contributor

@mattjohnsonpint mattjohnsonpint left a comment

Choose a reason for hiding this comment

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

Approved, with suggestions

SimonCropp and others added 2 commits June 24, 2022 08:25
Co-authored-by: Matt Johnson-Pint <matt.johnson-pint@sentry.io>
@SimonCropp SimonCropp merged commit 33d3b22 into main Jun 23, 2022
@SimonCropp SimonCropp deleted the expose-EnumerateChainedExceptions branch June 23, 2022 22:35
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.

3 participants