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

Reply via email to