this maybe a breaking(?) change for go/rust/no-exception languages

So for RUST at least - I'd tie the notion of "exception" to the presence of a backtrace on the error type.

Specifically, we want:

• In Rust, if you are signalling any type T which implements std::error::Error with a backtrace and are logging it, you fill out exception.stacktrace with the Backtrace from Rust.
• Following this guidance for accessing members by type on Error with a convention of attaching Backtrace as a field in Error.
• Ensuring this guidance works with anyhow crate.

If I read this guidance correctly, this means Rust would do the following:

• Always write error.type (the rust error type)
• Always write error.message (using description of the rust error)
• Optionally write exception.stacktrace (by accessing Backtrace field on Error when available.
• Optional write exception.type to match error.type if a Backtrace exists?

Can you confirm?

Also would be good for @open-telemetry/rust-maintainers to confirm my assumptions on error handling here.

https://github.com/open-telemetry/opentelemetry-rust/blob/main/opentelemetry-appender-tracing/src/layer.rs#L83-L93
This is what we do today (only error.message)

The note on the error.message attribute says it is NOT RECOMMENDED for spans. This text about duplicating error.message in the span status description may give the false impression that the attribute is preferred.

I think that a panic in Go be considered as an exception.
Then a deffered span.End can handle "the exception" (recover the panic and record it).
See: https://github.com/open-telemetry/opentelemetry-go/blob/b5b6989c7a08b5e4773236fc8d9fa0e5fe9788e1/sdk/trace/span.go#L476-L493

I think it would be good to clarify it.

@open-telemetry/go-maintainers,

While a personally like this distinction (and I find it correct), I am not sure if/how we are going to make it in Go in a non-breaking way given https://pkg.go.dev/go.opentelemetry.io/otel/trace#Span:

	// RecordError will record err as an exception span event for this span. An
	// additional call to SetStatus is required if the Status of the Span should
	// be set to Error, as this method does not change the Span status. If this
	// span is not being recorded or err is nil then this method does nothing.
	RecordError(err error), options ...EventOption)

Maybe deprecate this function and create a new one that would record errors according to the new semantics?

Related issues:

• otelhttp: Cannot record error for spans when producing new semantic convention opentelemetry-go-contrib#7254
• Span.End should record panic opentelemetry-go#6903
• Do not use span.RecordError for terminating errors opentelemetry-go-contrib#7470