Logging exceptions with context

[lmolkova]

Fix #44865

Exception messages don't contain all the useful information we put in logs (e.g. connection-id when connection drops).
This PR allows to create and log exception using the same context in log and inside the exception message:

throw logger.throwableAtWarning()
  .addKeyValue("connectionId", "foo")
  .addKeyValue("linkName", 1)
  .log("connection dropped", IOException::new);

Results in exception message like :

java.io.IOException: connection dropped; {"connectionId":"foo","linkName":1}

and log message:

{"message":"connection dropped","exception.type":"java.io.IOException","connectionId":"foo","linkName":1}

[azure-sdk]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

io.clientcore:core

[azure-sdk]

API change check

API changes are not detected in this pull request.

[Copilot]

Pull Request Overview

This pull request updates exception logging across the codebase to log additional context using the new throwableAtError()/log() methods instead of the previous logThrowableAsError() approach. Key changes include replacing exception throwing and logging patterns with more context-rich variants and removing unnecessary exception wrapping in various client, credential, and test classes.

Reviewed Changes

Copilot reviewed 104 out of 106 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
sdk/clientcore/core/src/main/java/io/clientcore/core/http/pipeline/HttpRetryPolicy.java	Updated exception logging in retry loops and interruption handling.
sdk/clientcore/core/src/main/java/io/clientcore/core/http/pipeline/HttpRedirectOptions.java	Simplified exception throwing using new logging methods.
sdk/clientcore/core/src/main/java/io/clientcore/core/http/pipeline/HttpPipelineBuilder.java	Added key/value context for invalid policy positions and updated logging style.
sdk/clientcore/core/src/main/java/io/clientcore/core/http/paging/PagedIterable.java	Changed logging when no more elements are available.
sdk/clientcore/core/src/main/java/io/clientcore/core/http/models/Response.java, HttpRequest.java, HttpRange.java, ETag.java	Updated exception logging methods to include contextual information.
sdk/clientcore/core/src/main/java/io/clientcore/core/http/client/JdkHttpClientBuilder.java	Refactored unsupported operation exceptions with new logging methods.
sdk/clientcore/core/src/main/java/io/clientcore/core/credentials/*	Updated key credential and named credential validations to use the new logging pattern.
sdk/clientcore/annotation-processor(-test)/*	Replaced wrapped RuntimeExceptions with more direct exception throwing and improved logging output.
sdk/clientcore/annotation-processor-test/src/main/java/io/clientcore/annotation/processor/test/*	In test implementations, updated exception handling to use HttpResponseException or UnsupportedOperationException as appropriate.

Files not reviewed (2)

• sdk/clientcore/core/checkstyle-suppressions.xml: Language not supported
• sdk/clientcore/core/spotbugs-exclude.xml: Language not supported

[alzimmermsft]

Per offline discussions, it'd be good to split up T log(String, Throwable, BiFunction<String, Throwable, T>) into a few different methods that better align with calls.

T log(String, BiFunction<String, Throwable, T>) becomes T log(String, Function<String, T) and T log(Throwable, BiFunction<String, Throwable, T>) becomes T log(Throwable, Function<Throwable, T>), so we don't need certain BiFunction values ignored if the constructor called by the BiFunction doesn't support String or Throwable.

This should be fine if we add it as part of release as the compiler should warn ahead of time when a calling pattern is invalid or ambiguous.

[JonathanGiles]

Really nice work! Thanks for doing this.