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

Application crashes when no internet connection!

Aug 29, 2012 at 4:28 PM

Hi Sascha,

The "invalid token '34'" error is because of an incomplete Json response from Twitter and that's the error message from the LitJson parser that I use.  To work around it, you should add logic to catch this exception and retry the query.  I expect this problem to be temporary.

If your application crashes, it's normally because of an unhandled exception. You can tell if this is happening by going to the Debug menu in VS, select exceptions (or Ctrl+D, E) and check on Thrown for CLR exceptions. This will cause VS to break into the debugger as soon as an exception is thrown.  If you do this, then you could send me info on the thrown exceptions (i.e. do a ToString on the exception in the immediate window).

Thanks for identifying the disconnected scenario.  I'll look at it closer to see what the current experience is or should be.


Sep 4, 2012 at 3:57 AM

Hi Sascha,

I did look at the disconnected scenario, where I disconnected my Internet connection to see what exceptions were raised.  I received a WebException that was very similar to the message you show above. During my investigation, I did find some exception handling code that did need to be cleaned up and was related to a couple other posts I've seen lately (re: "invalid token '34' in input string" that you mention above). So, it was a big win to find this.

Here are a few tips on what to look for in the disconnected scenario, described above:

  1. The most specific Exception type you can catch is TwitterQueryException, with is a LINQ to Twitter exception type.
  2. Check the InnerException for a WebException.
  3. In this scenario, the Status property of the WebException instance will be set to NameResolutionFailure. This is the tricky part because there are other WebExceptionStatus values that could exist, depending on the reason for the connection failure. Look at what you're getting back and handle as appropriate.
  4. Another bit of information is the Response property of the TwitterQueryException. In the disconnected scenario, this will only have the string value of the WebException info. i.e. message, stack trace, etc. In scenarios where Twitter returns an error, Response will often have important information from Twitter that will help you figure out what the problem is.
  5. If you get this exception, you can sleep the thread some number of milliseconds and retry. I usually do this with a linear backoff as Twitter does not respond well to rapid requests that are failing. In the disconnected scenario, Twitter will never hear you, so this isn't of great concern, but important to know since we're talking about exception handling strategies.
  6. If you get this exception (the TwitterQueryException with an InnerException of type WebException with a WebExceptionStatus.NameResolutionFailure or related WebExceptionStatus), then you would probably want to call the appropriate API for for your .NET Framework Profile to see if you have Internet connectivity and do what is appropriate for your application.

This is now checked in and you're welcome to download the code and give it a try. Let me know if you see any more strangeness.


Sep 4, 2012 at 3:53 PM

What type of application are you writing (i.e. WP7, Silverlight, Windows 8, WPF, etc.)?


Sep 5, 2012 at 5:23 AM

I just posted a WPF sample, showing how to handle exceptions in the disconnected scenario:

How is this different from what you're seeing?


Sep 10, 2012 at 4:06 PM

Throwing that exception is the correct thing to do.  It lets you know that the code is not able to perform its intended action.  Otherwise, you would be unaware of the situation.  In my sample, the application code that uses LINQ to Twitter catches and handles the exception.  Is there a problem where you aren't able to catch the exception?


Sep 19, 2012 at 6:37 PM

Good timing - I've been working on the LINQ to Twitter error handling, bringing it in-line with Twitter's new error message format.  I did find, and fix, an exception handling bug that is most likely the same issue you're seeing.

You can download the source code and let me know if that solved the problem.

Just a quick note - I'm upgrading LINQ to Twitter to Twitter API v1.1, which is what you will be downloading.  Naturally, some things have changed and I still have a few more things to do.


Sep 25, 2012 at 10:37 PM

Twitter has deprecated Public queries, so I need to remove that from the API - here's a recent post I did on LINQ to Twitter changes:

As discussed above, all API calls require authentication now.


Sep 28, 2012 at 4:48 PM

Technically, you could use SingleUserAuthorizer, but it wouldn't be a practical solution.  Do a Help/RateLimit query, which describes your rate limits.  Those rate limits are based on your access token.  So, using the same credentials on every client would likely result in everyone running into rate limit errors.  Imagine the trouble of trying to find a problem where your app works for some people and not others, where the problem comes and goes at different times for different people.

The best approach for multiple clients would be to have an initial authorization process the first time a user signs in.  You would use the ConsumerKey and ConsumerSecret for your app, but each person would have their own OAuthToken and AccessSecret. Save their credentials after the first time they authorize the app and then reuse those credentials thereafter.  They would only need to do this one time since Twitter doesn't change user tokens.