Skip to content

Commit 1f37350

Browse files
author
Liudmila Molkova
committed
move 'recording exceptions' to recording_errors.md doc
1 parent 7c037d7 commit 1f37350

File tree

2 files changed

+42
-52
lines changed

2 files changed

+42
-52
lines changed

docs/exceptions/README.md

Lines changed: 1 addition & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -7,61 +7,11 @@ path_base_for_github_subdir:
77

88
# Semantic Conventions for Exceptions
99

10-
**Status**: [Stable][DocumentStatus], Unless otherwise specified.
10+
**Status**: [Stable][DocumentStatus]
1111

1212
Semantic conventions for Exceptions are defined for the following signals:
1313

1414
* [Exceptions on spans](exceptions-spans.md): Semantic Conventions for Exceptions associated with *spans*.
1515
* [Exceptions in logs](exceptions-logs.md): Semantic Conventions for Exceptions recorded in *logs*.
1616

17-
## Reporting exceptions in instrumentation code
18-
19-
**Status**: [Development][DocumentStatus]
20-
21-
When an instrumented operation fails with an exception, instrumentation SHOULD record
22-
this exception as a [span event](exceptions-spans.md) or a [log record](exceptions-logs.md).
23-
24-
Recording exceptions on spans SHOULD be accompanied by:
25-
26-
- setting span status to `ERROR`
27-
- setting [`error.type`](https://github.com/open-telemetry/semantic-conventions/blob/main/docs/attributes-registry/error.md#error-type) attribute
28-
29-
Refer to the [Recording errors](/docs/general/recording-errors.md) document for additional
30-
details on how to record errors across different signals.
31-
32-
It's RECOMMENDED to use the `Span.recordException` API or logging library API that takes exception instance
33-
instead of providing individual attributes. This enables the OpenTelemetry SDK to
34-
control what information is recorded based on application configuration.
35-
36-
It's NOT RECOMMENDED to record the same exception more than once.
37-
It's NOT RECOMMENDED to record exceptions that are handled by the instrumented library.
38-
39-
For example, in this code-snippet, `ResourceAlreadyExistsException` is handled and the corresponding
40-
native instrumentation should not record it. Exceptions which are propagated
41-
to the caller should be recorded (or logged) once.
42-
43-
```java
44-
public boolean createIfNotExists(String resourceId) throws IOException {
45-
Span span = startSpan();
46-
try {
47-
create(resourceId);
48-
return true;
49-
} catch (ResourceAlreadyExistsException e) {
50-
// not recording exception and not setting span status to error - exception is handled
51-
// but we can set attributes that capture additional details
52-
span.setAttribute(AttributeKey.stringKey("acme.resource.create.status"), "already_exists");
53-
return false;
54-
} catch (IOException e) {
55-
// recording exception here (assuming it was not recorded inside `create` method)
56-
span.recordException(e);
57-
// or
58-
// logger.warn(e);
59-
60-
span.setAttribute(AttributeKey.stringKey("error.type"), e.getClass().getCanonicalName())
61-
span.setStatus(StatusCode.ERROR, e.getMessage());
62-
throw e;
63-
}
64-
}
65-
```
66-
6717
[DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status

docs/general/recording-errors.md

Lines changed: 41 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -52,7 +52,7 @@ When the operation ends with an error, instrumentation:
5252
When the operation fails with an exception, the span status description SHOULD be set to
5353
the exception message.
5454

55-
Refer to the [general exception guidance](/docs/exceptions/README.md) on capturing exception
55+
Refer to the [recording exceptions](#recording-errors) on capturing exception
5656
details.
5757

5858
## How to record errors on metrics
@@ -76,5 +76,45 @@ and metrics when both are reported. A span and its corresponding metric for a si
7676
operation SHOULD have the same `error.type` value if the operation failed and SHOULD NOT
7777
include it if the operation succeeded.
7878

79+
## Recording exceptions
80+
81+
When an instrumented operation fails with an exception, instrumentation SHOULD record
82+
this exception as a [span event](exceptions-spans.md) or a [log record](exceptions-logs.md).
83+
84+
It's RECOMMENDED to use the `Span.recordException` API or logging library API that takes exception instance
85+
instead of providing individual attributes. This enables the OpenTelemetry SDK to
86+
control what information is recorded based on application configuration.
87+
88+
It's NOT RECOMMENDED to record the same exception more than once.
89+
It's NOT RECOMMENDED to record exceptions that are handled by the instrumented library.
90+
91+
For example, in this code-snippet, `ResourceAlreadyExistsException` is handled and the corresponding
92+
native instrumentation should not record it. Exceptions which are propagated
93+
to the caller should be recorded (or logged) once.
94+
95+
```java
96+
public boolean createIfNotExists(String resourceId) throws IOException {
97+
Span span = startSpan();
98+
try {
99+
create(resourceId);
100+
return true;
101+
} catch (ResourceAlreadyExistsException e) {
102+
// not recording exception and not setting span status to error - exception is handled
103+
// but we can set attributes that capture additional details
104+
span.setAttribute(AttributeKey.stringKey("acme.resource.create.status"), "already_exists");
105+
return false;
106+
} catch (IOException e) {
107+
// recording exception here (assuming it was not recorded inside `create` method)
108+
span.recordException(e);
109+
// or
110+
// logger.warn(e);
111+
112+
span.setAttribute(AttributeKey.stringKey("error.type"), e.getClass().getCanonicalName())
113+
span.setStatus(StatusCode.ERROR, e.getMessage());
114+
throw e;
115+
}
116+
}
117+
```
118+
79119
[DocumentStatus]: https://opentelemetry.io/docs/specs/otel/document-status
80120
[SpanStatus]: https://github.com/open-telemetry/opentelemetry-specification/tree/v1.39.0/specification/trace/api.md#set-status

0 commit comments

Comments
 (0)