-
Notifications
You must be signed in to change notification settings - Fork 774
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
Added EnumerateTagValues Activity Extension #1236
Added EnumerateTagValues Activity Extension #1236
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1236 +/- ##
==========================================
+ Coverage 78.89% 78.98% +0.08%
==========================================
Files 219 219
Lines 6331 6347 +16
==========================================
+ Hits 4995 5013 +18
+ Misses 1336 1334 -2
|
{ | ||
return null; | ||
} | ||
Debug.Assert(activity != null, "Activity should not be null"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: consider the stock Assert.IsNotNull
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You want me to add Xunit to API? 🤣 I don't think there's a similar method on System.Diagnostics.Debug, but there should be!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not familiar with .NET, I thought Assert.IsNotNull is a common thing and am surprised that it is not (so it looks like a compile time trick).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry didn't mean to poke fun 😄 Ya it's common to unit test frameworks but I don't think there's anything in the BCL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I took a look at the doc and it makes me wonder if we should use it or throw normal exception.
It seems in C++ the general trend is to avoid https://en.cppreference.com/w/c/error/assert from a library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can switch them to regular null checks if you would like. My thinking with the Debug.Assert was... user will have to work really hard to call these extensions with a null Activity. You have to go out of your way and do OpenTelemetry.Trace.ActivityExtensions.GetTagValue(null, "myTag")
. If you are set on shooting yourself in the foot, who are we to stop you? 🤣 But for the 99.99% of callers who are doing activity.GetTagValue("myTag")
it really will never be null, so I was trying to save the perf of doing an unnecessary check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was trying to get your perspective and see if I need to change this
if (provider == null) |
Based on the discussion, I think we should remove the null check for extension methods?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is kind of a risk/reward thing. That particular extension would only be called a handful of times (?) so it's probably fine to leave the check in there. If we don't have the check, static analysis tools like FxCop get upset so then we end up with suppressions which are kind of a maintainability headache. IMO we should only do this on hot-path stuff where we know there is a compelling benefit to justify the suppression. Assuming we get to turning FxCop on 😄 Poor @eddynaka has been trying to do that for a while.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its getting harder and harder :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Coming into the middle of this conversation, though reminds me of System.Diagnostics.Contracts.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Changes
The ask on #1221 was for a way to find multiple tags. What I thought would be more useful is an extension for performing the allocation free foreach that users can call to do whatever they need with tags.
Usage
Define your state struct and implement the ForEach body. This must be a struct:
Call the extension, pass the state:
Use the state to retrieve any results you might need:
Benchmarks
CHANGELOG.md
updated for non-trivial changes