Losing information in unexpected error scenarios #138
In HttpHelper.cs we find this bit:
This works fine when you're querying a valid WordPress API well enough so you get a well formed bad request response. But in a wide range of error scenarios the call to DeserializeObject() blows up and throws an exception up the stack without logging some critical information, such as the HTTP response code and the URL being referenced. The Debug statement is arguably some help, but in most configurations that trace isn't going to hit a log file, which means if you've debugging a server issue you're staring at a now familiar error:
with no actionable information about what the underlying problem is. My suggestion is that we use an error handling delegate to catch the deserialization error and, in the event of a deserialization error, we record context information, including the HTTP status code, request URL, and possibly other details in some standard format, either using the existing BadRequest structure or possibly a new data format created for this purpose.
I'd be happy to submit a PR for this, but just wanted to get some review and guidance first.
and, I think, we could combine them together.