What's the usage pattern of HttpResponseMessage.EnsureSuccessStatusCode()? It disposes of the Content of the message and throws HttpRequestException, but I fail to see how to programmatically handle it any differently than a generic Exception. For example, it doesn't include the HttpStatusCode, which would have been handy.
Is there any way of getting more info out of it? Could anyone show relevant usage pattern of both EnsureSuccessStatusCode() and HttpRequestException?
The idiomatic usage of EnsureSuccessStatusCode is to concisely verify success of a request, when you don't want to handle failure cases in any specific way. This is especially useful when you want to quickly prototype a client.
When you decide you want to handle failure cases in a specific way, do not do the following.
var response = await client.GetAsync(...);
try
{
response.EnsureSuccessStatusCode();
// Handle success
}
catch (HttpRequestException)
{
// Handle failure
}
This throws an exception just to immediately catch it, which doesn't make any sense. The IsSuccessStatusCode property of HttpResponseMessage is there for this purpose. Do the following instead.
var response = await client.GetAsync(...);
if (response.IsSuccessStatusCode)
{
// Handle success
}
else
{
// Handle failure
}
(int)response.StatusCode (See msdn.microsoft.com/en-us/library/…) –
Gunar response.Content value before jumping into the // Handle success and // Handle failure blocks? In this way, you only read the response.Content property once. The only downside I can see to doing it this way is if the Content property is a long string, then you're basically slowing down the client, but if you're worried about speed, why not just use response.EnsureSuccessStatusCode();? –
Aminopyrine Content prior to checking the status. –
Aminopyrine I don't like EnsureSuccessStatusCode as it doesn't return anything meaninful. That is why I've created my own extension:
public static class HttpResponseMessageExtensions
{
public static async Task EnsureSuccessStatusCodeAsync(this HttpResponseMessage response)
{
if (response.IsSuccessStatusCode)
{
return;
}
var content = await response.Content.ReadAsStringAsync();
if (response.Content != null)
response.Content.Dispose();
throw new SimpleHttpResponseException(response.StatusCode, content);
}
}
public class SimpleHttpResponseException : Exception
{
public HttpStatusCode StatusCode { get; private set; }
public SimpleHttpResponseException(HttpStatusCode statusCode, string content) : base(content)
{
StatusCode = statusCode;
}
}
source code for Microsoft's EnsureSuccessStatusCode can be found here
Synchronous version based on SO link :
public static void EnsureSuccessStatusCode(this HttpResponseMessage response)
{
if (response.IsSuccessStatusCode)
{
return;
}
var content = response.Content.ReadAsStringAsync().GetAwaiter().GetResult();
if (response.Content != null)
response.Content.Dispose();
throw new SimpleHttpResponseException(response.StatusCode, content);
}
What I don't like about IsSuccessStatusCode is that it is not "nicely" reusable. For example you can use library like polly to repeat a request in case of network issue. In that case you need your code to raise exception so that polly or some other library can handle it...
EnsureSuccessStatusCode. You always dispose the response.Content (because finally is called always even after the return; statement) and it destroys the content for futher reading. Original implementation disposes the content only when status code does not indicate successful result. –
Uruguay await response.Content.ReadAsStringAsync() and then check if (response.Content != null) –
Analog HttpRequest calls, and configure the policy both to handle certain exceptions, and certain HttpResponseCodes. See the example in the Polly readme here –
Southey response.Content be null when it has just had a method called on it? –
Heyer For .NET 5.0 or later, HttpRequestException returns HttpStatusCode property, and you should be using that instead.
Below is my proposed solution for pre-.NET 5.0. The only flaw is that since the ASP.NET Core framework resource manager is internal to the framework, I cannot directly re-use Microsoft's internationalized message strings, so I'm just using the verbatim English message literal here.
ConfigureTestContainer<T>response.EnsureSuccessStatusCode(); and let the server deal with it.Content property prior to checking the status. There may be situations where this is not desirable, one of which is inefficiency.using (var requestMessage = new HttpRequestMessage(HttpMethod.Post, "controller/action"))
{
using (var response = await HttpClient.SendAsync(requestMessage))
{
var content = await response.Content.ReadAsStringAsync();
response.EnsureSuccessStatusCode2(content);
var result = JsonConvert.DeserializeObject<ResponseClass>(content);
}
}
public static class HttpResponseMessageExtensions
{
public static void EnsureSuccessStatusCode2(this HttpResponseMessage message, string content = null)
{
if (message.IsSuccessStatusCode)
return;
var contentMessage = string.IsNullOrWhiteSpace(content) ? string.Empty : $"Content: {content}";
throw new HttpRequestException(string.Format(
System.Globalization.CultureInfo.InvariantCulture,
"Response status code does not indicate success: {0} ({1}).{2}",
(int)message.StatusCode,
message.ReasonPhrase,
contentMessage)
);
}
}
I use EnsureSuccessStatusCode when I don't want to handle the Exception on the same method.
public async Task DoSomethingAsync(User user)
{
try
{
...
var userId = await GetUserIdAsync(user)
...
}
catch(Exception e)
{
throw;
}
}
public async Task GetUserIdAsync(User user)
{
using(var client = new HttpClient())
{
...
response = await client.PostAsync(_url, context);
response.EnsureSuccesStatusCode();
...
}
}
The Exception thrown on GetUserIdAsync will be handled on DoSomethingAsync.
Since Feb 24, 2020 the HttpRequestException.StatusCode property is set by EnsureSuccessStatusCode. If I understand correctly, the suggested extensions in this question are not needed anymore.
© 2022 - 2024 — McMap. All rights reserved.