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

Exception semantic conventions: Add example & more explanation for exception.escaped. #946

Merged

Conversation

Oberon00
Copy link
Member

@Oberon00 Oberon00 commented Sep 14, 2020

Follow up for #784 that recovers parts of #761. No semantic changes intended, just adds an example (with link from semantic conventions to recordException API) and an expanded explanation.

@Oberon00 Oberon00 added area:error-reporting Related to error reporting area:semantic-conventions Related to semantic conventions spec:trace Related to the specification/trace directory labels Sep 14, 2020
@Oberon00 Oberon00 changed the title Escaped example exception semantic conventions: Add example & more explanation for exception.escaped. Sep 14, 2020
Oberon00 and others added 2 commits September 14, 2020 17:11
Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Span span = myTracer.startSpan(/*...*/);
try {
// Code that does the actual work which the Span represents
} catch (Throwable e) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Wondering whether we should hold up adding this example till the actual API change hits OTel Java ;)

Copy link
Member Author

@Oberon00 Oberon00 Sep 14, 2020

Choose a reason for hiding this comment

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

@carlosalberto OTel Java already supports this API. But the actual API has more boilerplate (I think I would have to write AttributeValue.booleanAttribute(true) for the second parameter). See https://github.com/open-telemetry/opentelemetry-java/blob/v0.8.0/api/src/main/java/io/opentelemetry/trace/Span.java#L232-L239 (open-telemetry/opentelemetry-java#1599)

Copy link
Member Author

@Oberon00 Oberon00 Sep 14, 2020

Choose a reason for hiding this comment

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

I think the example is easier to read for non-Java users without that boilerplate, but I could add it too, if you prefer. Then I can write "Java" instead of "pseudo-Java" above.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd be personally more comfortable with the exact code we need (i.e. through Attributes). Else, go full pseudo code way :)

Copy link
Member Author

@Oberon00 Oberon00 Sep 14, 2020

Choose a reason for hiding this comment

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

@carlosalberto Now (d359f47) it's using the real OTel-Java API (at some version; seems like the Attributes are recently often changed)

Copy link
Contributor

Choose a reason for hiding this comment

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

We are trying to get the last changes through before GA, but Attributes should settle down here quite soon. :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Please continue at #946 (comment)

// Code that does the actual work which the Span represents
} catch (Throwable e) {
span.recordException(e, Attributes.of(
"exception.escaped", AttributeValue.booleanAttributeValue(true)));
Copy link
Member

Choose a reason for hiding this comment

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

AttributeValue.booleanAttributeValue ? Could it not be just AttributeValue.of(true)?

Copy link
Member

Choose a reason for hiding this comment

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

"exception.escaped" - in OpenTracing we usually had strongly typed constants for semantic conventions. E.g. something like this would be much more user friendly:

span.recordException(e, Attribute.Exception.Escaped(true))`

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually it should be possible to use (soon) SemanticAttributes.EXCEPTION_ESCAPED.set(span, true).

Copy link
Member Author

@Oberon00 Oberon00 Sep 15, 2020

Choose a reason for hiding this comment

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

@yurishkuro This example should be easy to read. Then @carlosalberto said in #946 (comment) I should use the actual Java API, so I added the boilerplate. Now you are saying the boilerplate looks verbose. Please decide this among you two, personally I would prefer readability over "real code" here. And for that matter, I think a literal string is far less confusing than a constant.

Copy link
Member Author

Choose a reason for hiding this comment

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

@carlosalberto This won't work for event attributes that way. I would probably have to call getKey(), wouldn't I?

Copy link
Member Author

Choose a reason for hiding this comment

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

I added f78003e to simplify the code again. It is now readable pseudo-Java and I prefer it that way.

@Oberon00 Oberon00 changed the title exception semantic conventions: Add example & more explanation for exception.escaped. Exception semantic conventions: Add example & more explanation for exception.escaped. Sep 15, 2020
CHANGELOG.md Outdated Show resolved Hide resolved
@Oberon00
Copy link
Member Author

Whoops, it seems I need to switch to YAML now 😅 Since I don't have Docker installed, this may take a while to get rebased...

CHANGELOG.md Outdated Show resolved Hide resolved
@Oberon00
Copy link
Member Author

Rebased and moved the new subsection to the "note" of exception.escaped. @carlosalberto @yurishkuro please check if the example is OK now.

Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
See the [example above](#exception-end-example). It follows that an exception
may still escape the scope of the span even if the `exception.escaped` attribute
was not set or set to false, since that event might have been recorded at a time
where it was not clear whether the exception will escape.
Copy link
Member

Choose a reason for hiding this comment

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

Sorry, I find this paragraph exceedingly confusing. The first sentence says "difficult to say X, but trivial to say X" (X==X). The terms "in flight" and "escape" are undefined (and not a particularly common lingo). "in flight" exception, specifically, is not observable by the code, whereas a caught exception is not "in flight".

Terms that are not ambiguous: catch exception, re-throw exception.

Copy link
Member Author

Choose a reason for hiding this comment

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

These terms are not ambiguous but also not appropriate here. If you look at the code without the auto-instrumentation in place, the exception would indeed be currently in a state where it was thrown but not yet caught.

Copy link
Member Author

@Oberon00 Oberon00 Sep 19, 2020

Choose a reason for hiding this comment

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

@yurishkuro I tried to clarify in 350ff89 although I think it would also be OK to be more vague here. WDYT?

@yurishkuro yurishkuro merged commit c3982b5 into open-telemetry:master Sep 19, 2020
@Oberon00 Oberon00 deleted the escaped-example branch December 18, 2020 10:59
carlosalberto pushed a commit to carlosalberto/opentelemetry-specification that referenced this pull request Oct 31, 2024
…ception.escaped. (open-telemetry#946)

* Add example & explanation for exception.escaped.

* Reshuffle paragraphs.

* Remove potentially controversial changes.

* Fill in CHANGELOG link.

* Address review comments.

* Wording

Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>

* Use actual OTel-Java API.

* Revert "Use actual OTel-Java API."

This reverts commit d359f47.

* Clarify CHANGELOG

* Re-generate tables.

* Typo in CHANGELOG.md

Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>

* Clarify exception escaped description.

Co-authored-by: Tigran Najaryan <4194920+tigrannajaryan@users.noreply.github.com>
Co-authored-by: Armin Ruech <armin.ruech@dynatrace.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:error-reporting Related to error reporting area:semantic-conventions Related to semantic conventions spec:trace Related to the specification/trace directory
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants