0

When I process a json response wich may be an error, I use this method to determine wether the json is actually an error or may be an expected response :

bool TryParseResponseToError(string jsonResponse, out Error error)
{
    // Check expected error keywords presence
    // before try clause to avoid catch performance drawbacks
    if (jsonResponse.Contains("error") &&
        jsonResponse.Contains("status") &&
        jsonResponse.Contains("code"))
    {
        try
        {
            error = new JsonSerializer<Error>().DeserializeFromString(jsonResponse);
            return true;
        }
        catch
        {
            // The JSON response seemed to be an error, but failed to deserialize.
            // It may be a successful JSON response : do nothing.
        }
    }

    error = null;
    return false;
}

But, I have an empty catch which is a bad code smell.

I did not see any TryToDeserialize kind of method in ServiceStack libraries. Is there any ?

How do you process json errors with ServiceStack ?

Dude Pascalou
  • 2,989
  • 4
  • 29
  • 34
  • 1
    You could built your own `TryToDeserialize` extension method. By the way, it seems like almost every uses [JSON.NET](http://json.net/) instead of the built-in serializer. – mason May 27 '14 at 14:29
  • Extension method is a good idea, thanks. Can you provide me more details about the Json.Net way instead of JsonSerializer ? – Dude Pascalou May 27 '14 at 14:33
  • You'll just need to check their documentation out, it's pretty good. I'm with @tvanfosson on this, you should use HTTP status codes and not JSON objects to represent errors. – mason May 27 '14 at 14:36
  • Yes, I agree that would be way better... But I do not own this service. – Dude Pascalou May 27 '14 at 14:40
  • My question was not well asked, I rephrased it here : [Deserialize json in a “TryParse” way][1] [1]: http://stackoverflow.com/questions/23906220/deserialize-json-in-a-tryparse-way – Dude Pascalou May 28 '14 at 08:19

3 Answers3

1

For ServiceStack, the error handling is well documented: https://github.com/ServiceStack/ServiceStack/wiki/Error-Handling

Basically, you will get an HTTP 400, 405, 403, or 500 status response on error.

Otherwise, you can treat it as a success.

If it is an error you will receive in the JSON response a ResponseStatus DTO. It contains properties:

  • public string ErrorCode
  • public string Message
  • public string StackTrace
  • public List<ResponseError> Errors

That should give you what you want.

Update: If you actually do not have any control or knowledge of the service code or the errors sent out, and you are writing a HTTP client application, you will need to manually inspect what the service is returning "over the wire".

In other words, you expect the service is returning an error in the response JSON, but you do not know what the format of the JSON is. Thus, you cannot serialize it to a type.

A good way to inspect the HTTP response JSON is to use the Fiddler utility. It will install itself in between your web browser and the remote web server (as a proxy). You can hit the service url, and then look in the Fiddler response (JSON or RAW). Once you see the raw response, you will have a clue on how to create a C# class which is suitable to serialize the JSON to.

Raul Nohea Goodness
  • 2,549
  • 23
  • 24
  • I just realized one thing : I do not own the service I request, and I do not know if it is a ServiceStack's one. Actually, I just use the JsonSerializer to Deserialize a given json response. My question is not well asked... – Dude Pascalou May 27 '14 at 14:49
  • If that is the case, i recommend updating your question to remove the servicestack tag and ask: How to i use JsonSerializer to deserialize a json response, which i do not know the error format for? – Raul Nohea Goodness May 27 '14 at 15:19
0

This seems to be a bad way to check for the presence of errors. Generally you will try to have some kind of a response object with has your error object as a member variable. You need to de-serialize the jsonResponse string to response object to properly segregate all the required fields. This way you can avoid the empty catch block and have better handle over de-serialization.

Karthik
  • 1,005
  • 8
  • 7
  • Thanks for the instant anwser. Unfortunately, I do not own the service and I have to deal with that : an error is sent back with HTTP 200 OK. And a response is either only the data, or only the error. – Dude Pascalou May 27 '14 at 14:41
0

Generally I want to use HTTP status codes to signal errors rather than encode them in the expected message format. So a 200 OK response would contain valid JSON data from the API, but other response, i.e., 4xx, 5xx, indicate errors. In the latter cases, you'd decode the message as an error rather than the expected response.

In cases where that's not possible, perhaps due to historical reasons, the pattern I've seen is to use a wrapper around the JSON object.

Error:

{
   success = false,
   message = "There was an error.",
   data = null
}

Success:

{
    success = true,
    message = null,
    data = { .... }
}
tvanfosson
  • 524,688
  • 99
  • 697
  • 795
  • Thanks for the lightning fast answer. Unfortunately, the requested service does not process responses like that (and I have no way to change that) : an error is sent back with HTTP 200 OK. And a response is either only the data, or only the error. – Dude Pascalou May 27 '14 at 14:38