Handling errors codes

Question

By developing some error handling code inside my Unity application in order to take custom actions when a request to Facebook fails (as forcing a local user logout or requesting a new permission) I saw some inconsistencies between the Facebook Graph API (Handling error codes) documentation and the results I am receiving for failed requests.

When trying to post a score (Scores API) without granting write permissions to my application, the request assigned callback receives a FBResult containing:

result.Error == "403 Forbidden"

instead of something related to:

result.Error == {
    "error": {
        "message": "API Permission Denied", 
        "type": "", 
        "code": 10 ,
        "error_subcode": 467
    }
}

When looking to the FB sample friendsmash-unity they only ignore errors as presented in the next code snippet:

void APICallback(FBResult result)
{
    Util.Log("APICallback");
    if (result.Error != null)
    {
        Util.LogError(result.Error);
        // Let's just try again
        FB.API("/me?fields=id,first_name,friends.limit(100).fields(first_name,id)", Facebook.HttpMethod.GET, APICallback);
        return;
    }

1. Is Facebook using different patterns between the Graph API and the Scores API for handling errors?

2. Do I need to implement both JSON error and HTTP error parsers?

3. What are the best practices for handling Facebook errors inside a Unity application?

Answer 1

1) There are some limitations to Unity's WWW class that unfortunately doesn't let us give back more meaningful errors. They are in the process of fixing it so in the future, result.Error would give back an error message and result.Text would be populated with more meaningful details on the error when that happens. The Scores API and Graph API should be using the same pattern. Though there are still some inconsistencies in how the error comes back. If you do find something like that, please let us know in our bug reporting tool: https://developers.facebook.com/bugs

2) To safely guard yourself, I would say yes. It'll be a good practice to ensure your game is robust.

3) The pattern we try to follow with the Graph API is that it shouldn't return an error code unless something goes wrong. Then it should return an HTTP error code and result.Error should be populated. So the best way is to check if something is in result.Error and handle it from there. If you find something that's not the case, please let us know.