Marc,
Nice theory but I'm not so sure since I'm reloading the same exact tweet (I
think)over and over again and its getting corrupted.
Although I've heard of type of thing before where an application (notepad)
tries to do charset encoding detection but fails and outputs a corrupted
file upon reopening.
On Jun 14, 2011 9:24 PM, "marc fawzi" <marc.fa...@gmail.com> wrote:
>
> 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 <iordan.rom...@gmail.com> 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

-- 
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

Reply via email to