[dotnet] Do not intercept exceptions from ICommandExecutor.ExecuteAsync

[RenderMichael]

User description

Thanks for contributing to Selenium!
A PR well described will help maintainers to quickly review and merge it

Before submitting your PR, please check our contributing guidelines.
Avoid large PRs, help reviewers by making them as simple and short as possible.

Description

This removes an unnecessary use of Response, which would throw an exception in the subsequent UnpackAndThrowOnError anyway.

Motivation and Context

This code stores an Exception into Response.Value. This is the only usage of that type to store anything other than a JSON-deserialized response, which the custom converter handles to only contain bool, long, double, string, List<object>, or Dictionary<string, object>.

This change makes it so we can assume Response.Value is always one of those types.

While trying to test this, I noticed this code path is unreachable by normal means anyway. The HttpRequestException is caught earlier on and turned into a normal WebDriverException.

selenium/dotnet/src/webdriver/Remote/HttpCommandExecutor.cs

Lines 201 to 205 in 4ea71ca

	catch (HttpRequestException ex)
	{
	string unknownErrorMessage = "An unknown exception was encountered sending an HTTP request to the remote WebDriver server for URL {0}. The exception message was: {1}";
	throw new WebDriverException(string.Format(CultureInfo.InvariantCulture, unknownErrorMessage, requestInfo.FullUri.AbsoluteUri, ex.Message), ex);
	}

However, this code path may be hit if an advanced user supplies their own ICommandExecutor in the WebDriver constructor. Therefore, this catch block is still meaningful.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

---

PR Type

enhancement, bug_fix

---

Description

• Removed unnecessary indirection through the Response object when handling HttpRequestException in WebDriver.cs.
• Directly throws a WebDriverException with a clear error message, improving code clarity and error handling.
• Ensures that Response.Value is not used to store exceptions, aligning with the expected data types.

---

Changes walkthrough 📝

	Relevant files
Enhancement	WebDriver.cs Simplify exception handling for HTTP requests in WebDriver dotnet/src/webdriver/WebDriver.cs Removed the creation of a Response object in the catch block for HttpRequestException. Threw a WebDriverException directly with a descriptive message. +1/-5

---

💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

[qodo-merge-pro]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 1 🔵⚪⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Error Handling The new implementation throws the exception immediately instead of wrapping it in a Response object. Verify this doesn't break error handling expectations for custom ICommandExecutor implementations.

[qodo-merge-pro]

PR Code Suggestions ✨

No code suggestions found for the PR.

[nvborisenko]

Is it something related for further AOT compatibility?

[RenderMichael]

This is a general improvement, but it does pave the way to strongly-typed Reponses, instead of relying on object? Value.

This may not give any AOT advantages, but it would be a huge improvement (avoid the annoying double-null-check when doing object.ToString(), random null reference exceptions like I fixed in #14737, etc.)

Best of all, it can be done without any breaking changes.

[nvborisenko]

CI failure is not relates to these changes, thanks @RenderMichael for contribution.