This project has moved and is read-only. For the latest updates, please go here.

Handling Errors in Linq2Twitter v3.0.2

May 4, 2014 at 10:37 PM
Edited May 4, 2014 at 10:54 PM
I just updated LinqToTwitter in my app and am getting used to the new async, awaitable ways of doing things.
Before, when an exception occurred, it would be wrapped in a TwitterAsyncResponse object. Now, responses don't seem to be returned inside TwitterAsyncResponses, so I'm not quite sure where to find the exceptions.
Would the correct implementation be something like this?

                        var resp = await TwitterCtx.CreateFriendshipAsync(id, false);
                    catch (TwitterQueryException ex)
                         //handle the exception here, like
                         if (ex.ErrorCode == 88) //rate limit exceeded
In this case, resp is simply a User object and doesn't contain any exception data if an exception was to be thrown
Also, if the error was not a problem with Twitter and it was, say, a WebException, can that Exception be found in ex.InnerException?
Thank you for your help!

Since I have you already, I figured I'd clarify a few other things as well haha
Before, there was a PinAuthorizer.IsAuthorized property. Now, I'm assuming that it's been replace by PinAuthorizer.CredentialStore.HasAllCredentials(), correct?
Also, I can't find an AccessToken property in InMemoryCredentialStore, but there is OAuthTokenSecret. Is this the new version of AccessToken?
Thanks again!
May 5, 2014 at 2:35 AM

All exceptions should be thrown as TwitterQueryException. There's an error code, which is from the Twitter API. There is also a StatusCode, which is the HTTP status code. e.g. if you try to create a friendship with a user that doesn't exist, you might see a 404 (Not Found). Message holds the Twitter API error message. In previous versions, error handling was a catch, wrap, and throw process. Now the code detects that an error has occurred and uses a special error handling routine to intelligently build a TwitterQueryException with meaningful info. e.g. a 401 would provide a meaningful message about what happened with a url for the LINQ to Twitter FAQ. There's more work to do in this area, but the infrastructure is now in-place to make it easier to customize error handling.

Correct, use HasAllCredentials as a convenience method to know that you've populated credentials. To find out if the credentials are valid, you can do an Account/VerifyCredentials query.

Look at TwitterAccessToken and TwitterAccessTokenSecret, which are named more accurately to reflect the Twitter API naming. They are properties of the SingleUserInMemoryCredentialStore.

For more info on differences, the API docs show queries in the old and new version syntax.

Marked as answer by elliottvforde on 5/5/2014 at 3:29 PM
May 5, 2014 at 11:30 PM
Thanks for your help!