The common approach seems to be:

• do nothing if the exception is handled by the instrumented library (retries, etc)
• for unhandled (by client lib) exceptions:
  • set span status to error
  • set span status description to exception message
  • set error.type attribute on spans/metrics based on the exception type or more specific low-cardinality error code
  • DO NOT record exception event (by default) unless recording local root span or when the instrumentation knows that user code didn't handle the exception. Reason: exceptions are huge and expensive. Users decide if/how to record them when they catch them. If exception stays unhandled, the server instrumentation will record it.

We should document it and link from DB/messaging/gen-ai and other conventions.