-
-
Notifications
You must be signed in to change notification settings - Fork 448
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
Proposed new performance API (runTransaction) #1154
Comments
it'd also be nice to have something similar to |
not totally related to this issue. if we make we could use try-with-resources, idea from @untitaker:
|
try with resources is usually used when without proper closing, some resources will be kept open leaving file handles, open sockets etc open in the OS. Isn't using it for span/transaction use case a bit of misuse? |
yes, I agree, although it's been used by some other SDKs/libs to kinda reduce boilerplate, improving user experience over correctness. |
the only advantage I see with try-with-resources is that runTransaction would have to be built for sync/async functions each |
This relates to the the .NET version of it: getsentry/sentry-dotnet#801 One downside is that there's no clean way to mark the span status to failed when there's an exception (or to attach the exception to the Span) |
Java doesn't have async. But yeah returning |
we agreed that such callback makes sense and reduces boilerplate for manual instrumentation. so ideally
|
This would require TSC discussion to align SDKs and plan ahead. |
The proposal for this API:
Where
runTransaction
method would look like:With such simple API we don't give a an option to set different status on error, but it can be a good enough tradeoff.
From: #1151 (comment)
First usage of it: #1058 (comment)
Downside is that we have to account for
async
and callbacks with return type.Alternative
Alternative APIs to make it less boilerplate but without going full on wrapping a callback:
This way we can extend the mapping between
Throwable
andSpanStatus
. Other overloads that take aHttpStatus
for example could also fit well.finish
parameterless would assumeOK
.The text was updated successfully, but these errors were encountered: