Improve HttpClient exception docs #11103
Conversation
|
Tagging subscribers to this area: @dotnet/ncl |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
|
Learn Build status updates of commit e78a667: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
| @@ -2536,8 +2695,10 @@ The size specified is greater than the maximum allowed buffer size.</exception> | |||
|
|
|||
| ]]></format> | |||
| </remarks> | |||
| <exception cref="T:System.InvalidOperationException">The <paramref name="requestUri" /> must be an absolute URI or <see cref="P:System.Net.Http.HttpClient.BaseAddress" /> must be set.</exception> | |||
| <exception cref="T:System.Net.Http.HttpRequestException">The request failed due to an issue getting a valid HTTP response such as network connectivity failure, DNS failure, server certificate validation error or invalid server response. On .NET 8+ the reason is indicated by <see cref="P:System.Net.Http.HttpRequestException.HttpRequestError" /></exception> | |||
| <exception cref="T:System.OperationCanceledException">The cancellation token was canceled or the request failed due to timeout.</exception> | |||
There was a problem hiding this comment.
What is the reason to drop "This exception is stored into the returned task"?
There was a problem hiding this comment.
HttpClient API docs follow a the nonstandard practice of documenting every stored exception for the async methods as a normal exception. Having the "This exception is stored into the returned task" line just for the OperationCanceledException felt odd.
We can open a tracking issue to add the line for every exception, but in this PR I wanted to harmonize the content around the most common practices in HttpClient docs.
Co-authored-by: Genevieve Warren <[email protected]>
|
Learn Build status updates of commit 060db12: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
HttpRequestExceptionmight be thrown.PatchAsync.EnsureSuccessStatusCode.Get(ByteArray|Stream|String)Async, calling out that in some cases manual status code validation might be a better optionThe PR does not touch the
HttpClientJsonExtensionsdocs, I'm planning to do it in a separate PR.Fixes #9148