Mark exceptions as stable. We do not plan to change this behavior in…

[jsuereth]

… breaking ways.

We discussed the current exception specification. Today, the specification defines how exceptions show up in spans. It's been in use for a while and we don't want to create breaking changes. We believe we can evolve the specification we have as needed in non-breaking ways.

[jack-berg]

We've talked about potential long terms plans to instead record span events as event logs records. This isn't a blocker for stabilizing recording exception as span events since anything we do replacing span events with event log records must be done in a way that allows the spec to evolve gracefully.

Stabilizing this is long overdue.

[trask]

I agree. It's hard to argue against stabilizing this since it's part of all of the stable SDKs already.

I'm assuming this means we'll mark the exception.* attributes as stable in the semantic-conventions repo?

[tigrannajaryan]

I agree with should stabilize. The only question to me is if we are happy with exception. as the namespace. This came up in a recent discussion about events. One possible alternate surfaced was runtime.exception.

[jsuereth]

I agree with should stabilize. The only question to me is if we are happy with exception. as the namespace. This came up in a recent discussion about events. One possible alternate surfaced was runtime.exception.

In Semconv we use reasonably unique namespaces that are meant to be minimal. runtime carries a lot of baggage here and walks into the errors vs. exceptions space. I don't think that discussion is worth revisiting again.

I'm assuming this means we'll mark the exception.* attributes as stable in the semantic-conventions repo?

Yes, we can/should mark some of these as stable. This specification update only outlines what fields are filled out, not what they contain.

[cijothomas]

Thanks!

Languages like OTel.NET have shipped this already as part of stable API un-intentionally for a very long time.!

[carlosalberto]

Overall LGTM, but I'm slightly wary of the fact the actual semconv values are mentioned at the bottom of this document. Should we remove them altogether and keep the link to their semconv section?

[tigrannajaryan]

@jack-berg I did not attend the last Events WG meeting. Have you had a chance to discuss this?

[jack-berg]

@jack-berg I did not attend the last Events WG meeting. Have you had a chance to discuss this?

No we did not. The 11/24 Event WG is cancelled due to US holiday, so the next opportunity is 12/08.

Personally, I think there are strong reasons to stabilize this without the agreement of the Event WG, although this is not to say that I anticipate disagreement from the Event WG. I think the Event WG needs to find a way to evolve around this behavior rather than delaying stabilization and shifting course.

[lmolkova]

I assume once it's merged we're going to also mark corresponding attributes as stable in the yaml and md in the semconv repo?

[jsuereth]

@lmolkova See #3769 (comment)

Yes, we'll be looking to stabilize those too.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[arminru]

Not stale, just making sure there was enough time for reviewing before merging it.