Use consistent exception logging format

[p-datadog]

What does this PR do?

Standardizes exception logging across lib/datadog/ to use the consistent format #{e.class}: #{e} instead of various inconsistent patterns like e.message, e.class.name #{e.message}, or e.class}: #{e.message}.

This touches 59 files, but every change follows the same mechanical pattern — no logic changes, just formatting consistency.

Motivation:

Exception#to_s and Exception#message have different contracts in Ruby. Subclasses can override them independently, and to_s is the method Ruby calls during string interpolation ("#{e}"). Using e.message directly can produce different output than #{e} when a subclass overrides one without the other.

Similarly, e.class already returns a displayable class name via its own to_s, making the extra .name call redundant in string interpolation.

The codebase convention is #{e.class}: #{e}. This PR brings all logging call sites in line with that convention.

Log output changes:

This is a formatting change, not a logic change, but the log output customers see does change:

• Lines that previously logged only e.message (no class) now include the exception class name (e.g. "Test failure" → "RuntimeError: Test failure")
• Lines that used a space separator between class and message (e.class.name e.message) now use a colon separator (e.class: e)
• e.message is replaced with #{e} (calls to_s instead of message) — identical for standard exceptions, but could differ for subclasses that override one without the other

What was NOT changed (intentionally):

• e.message used for constructing new exceptions (raise SomeError, e.message)
• e.message used in data structures or API payloads (e.g., error_message: fields)
• e.message in Core::Error.build_from (value object construction)
• e.message in conditionals or comparisons
• payload[:exception] = [e.class.name, e.message] (Rails convention)
• Test files

Change log entry

None.

Additional Notes:

AI-assisted.

How to test the change?

This is a logging format change only. Existing tests should continue to pass. The change can be verified by:

• Confirming no e.message remains in logger calls under lib/datadog/
• Reviewing the diff to confirm each change is in a logging context
• Running the existing test suite

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-04-09 15:36:29

Comparing candidate commit e451652 in PR branch claude-9/fix-exception-message-format with baseline commit 2365975 in branch master.

Found 0 performance improvements and 0 performance regressions! Performance is the same for 45 metrics, 1 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

[datadog-datadog-prod-us1-2]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage (details)
• Patch Coverage: 45.05%
• Overall Coverage: 95.26% (-0.09%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: e451652 | Docs | Datadog PR Page | Was this helpful? React with 👍/👎 or give us feedback!}

[p-datadog]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Hooray!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[vpellan]

LGTM! Maybe we could create a custom cop to enforce that?

[p-datadog]

@vpellan I created #5582 for the cop.