Re: error handling the jsonp "script error" I started using the previously mentioned "window.onerror" mechanism wherein I reload the iframe from which I'm initiating the jsonp call, up to 10 times, 3 seconds apart (the average delay in getting the script back from twitter, which triggers the error which in turn starts another jsonp request and so on, up to 10 times)
I'm using this approach in addition to my pre-existing "5 retries on general error, 10 seconds apart" non-blocking error handler which was able to survive the "illegal character" error on its own and recover from it, but sometimes it ended up with "Sorry, try again later" (twitter recovers after a while on its own and my app continues from there but sometimes the error persists with twitter.) The pre- existing handler was using more time on average (about 20-50 seconds) and the newly added window.onerror mechanism, which runs before the self-terminating, non-blocking handler loop, is taking less time on average (6-15 seconds) to go thru the same process for the jsonp "script error" reported by the browser. However, sometimes, this error persists for too many retries and falls out of the window.onerror but 99% of the time so far it's getting caught by my pre-existing general error handler (now, the second layer of defense) I never thought I had to double up! :) Re: illegal character Wow. Really? you can have the unicode character for "delete" \u0008 in the response? I have a full dump of the jsonp response in firebug and that's the character that firebug terminates at when reporting the error so I assume that's the culprit, but could be others as well. On a more relevant note, I don't think the illegal character coming back in jsonp have anything to do with the tweet's content. It looks as if some tweets contain some combination of characters that cause twitter to return a binary dump of some sort (in casual terms, it causes it to hallucinate.) Anyway.... intriguing. :) Marc On Jun 14, 6:53 pm, Romica <[email protected]> wrote: > I have the same problem (bad JSON most of the times). The weird thing > is that if I access the URL direct from the browser it works (good > JSON every time). I'm using jQuery.getJSON and I think that this (or > something connected to this) might be the problem. > > Unfortunately I cannot use window.onerror (as Michael suggested) > because I have multiple asynchronous requests at the same time (it > would be tricky and expensive to find out which one is bad - at least > I suppose so). > > Good luck in solving this -- Twitter developer documentation and resources: https://dev.twitter.com/doc API updates via Twitter: https://twitter.com/twitterapi Issues/Enhancements Tracker: https://code.google.com/p/twitter-api/issues/list Change your membership to this group: https://groups.google.com/forum/#!forum/twitter-development-talk
