-
Notifications
You must be signed in to change notification settings - Fork 426
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
5 changed files
with
103 additions
and
154 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
30 changes: 3 additions & 27 deletions
30
releasenotes/notes/feat-add-dd-record-exception-033fd0436dfd2723.yaml
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,30 +1,6 @@ | ||
--- | ||
#instructions: | ||
# The style guide below provides explanations, instructions, and templates to write your own release note. | ||
# Once finished, all irrelevant sections (including this instruction section) should be removed, | ||
# and the release note should be committed with the rest of the changes. | ||
# | ||
# The main goal of a release note is to provide a brief overview of a change and provide actionable steps to the user. | ||
# The release note should clearly communicate what the change is, why the change was made, and how a user can migrate their code. | ||
# | ||
# The release note should also clearly distinguish between announcements and user instructions. Use: | ||
# * Past tense for previous/existing behavior (ex: ``resulted, caused, failed``) | ||
# * Third person present tense for the change itself (ex: ``adds, fixes, upgrades``) | ||
# * Active present infinitive for user instructions (ex: ``set, use, add``) | ||
# | ||
# Release notes should: | ||
# * Use plain language | ||
# * Be concise | ||
# * Include actionable steps with the necessary code changes | ||
# * Include relevant links (bug issues, upstream issues or release notes, documentation pages) | ||
# * Use full sentences with sentence-casing and punctuation. | ||
# * Before using Datadog specific acronyms/terminology, a release note must first introduce them with a definition. | ||
# | ||
# Release notes should not: | ||
# * Be vague. Example: ``fixes an issue in tracing``. | ||
# * Use overly technical language | ||
# * Use dynamic links (``stable/latest/1.x`` URLs). Instead, use static links (specific version, commit hash) whenever possible so that they don't break in the future. | ||
features: | ||
- | | ||
tracing: This introduces the record_exception tracer api. It allows to manually add an exception as a span event. | ||
It also allows to tag a span with an error tuple of the recorded exception by setting the escaped parameter as true. | ||
tracing: tracing: Introduces a record_exception method that adds an exception to a Span as a span event. | ||
Refer to [Span.record_exception](https://ddtrace.readthedocs.io/en/stable/api.html#ddtrace.trace.Span.record_exception) | ||
for more details. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters