[...]Unifying HTTP success and failure in .NET « Jon Udell[...]…

[...]Unifying HTTP success and failure in .NET « Jon Udell[...]…

[...]Unifying HTTP success and failure in .NET « Jon Udell[...]…

No worries, I am very green in C# and don’t pretend otherwise.

> in naming convention

What do you prefer and why?

> and in what it actually does

FWIW, this wrapper isn’t just a way to guarantee a response, but also to package up everything for downstream inspection — not just in a debugger but, frequently, from an IronPython client.

> you can even build this as a sexy
> extension method

Very nice. Thanks!

public static class HttpWebRequestExtensions {
public static HttpWebResponse GetResponse(this HttpWebRequest request) {
HttpWebResponse result;

try {
result = request.GetResponse() as HttpWebResponse;
} catch (WebException ex) {
result = ex.Response as HttpWebResponse;
}

return result;
}
}

to invoke the extension method, just do the following:

HttpWebResponse response = request.GetResponse();

I completely agree that it’s moronic of the HttpWebRequest class to throw exceptions when the status code is above or equal to 400. At least, it should be configurable. As an example, “410 Gone” is, after all, not an exception, but an expected response that can and should be handled gracefully.

A simple switch(response.StatusCode) is the best way to handle all possible status codes and It’s really painful that Microsoft won’t allow this out of the box.

PS: Comment preview would have been awesome.

to mitigate the status problem we use something like (sorry if the markup’s broken):

static HttpWebResponse GetHttpWebResponse (HttpWebRequest r) {
HttpWebResponse result;
try {
result = r.GetResponse() as HttpWebResponse;
} catch (WebException e) {
if (e.Response is HttpWebResponse) {
result = e.Response as HttpWebResponse;
} else {
result = null;
}
}
return result;
}

(you still have to test for null, though)

Regards,
tamberg