Thanks for the replies guys, I understand what you're trying to say
and I understand how it works.
@Ryan; I can read the error in the consoles just fine ;) I just wanted
to use it for output to the user or do something with it (fix it when
possible) and continue).

Catching an error like Fabio suggested is something, at least.. I mean
it's fair to say there's an error if the callback didn't fire after
the script is loaded.

In the case I'm using it (echonest btw) it loads the script fine, it's
just the send params can be wrong and then it returns the 400 response
with an error message in json telling which param was wrong... so it's
a handy error response really. I was throwing together an API wrapper
for it and thought about describing all available methods with input
checking before sending the request (and that way catch possible error
before sending), but if I could read the actual response it would be
easier and I could throw the error to the user as well ("hey, param X
is invalid, fix your sh*t, check the docs").

I don't have to use jsonp, could use a standard request and check
error codes with it, but tried jsonp cause I didn't work with it
before.


On Jul 7, 5:24 am, Fábio M. Costa <[email protected]> wrote:
> I've been thinking about an implementation of error detection.
> You can check if the script tag is loaded, this is cross-browser, so... If
> the script has loaded (independent of the http status code) and the callback
> has not executed, lets say 200 ms after, we can say that we got some kind of
> error.
>
> Still i can't tell you too much about what error it gave... but something
> didn't go ok and your data was not retrieved.
>
> Feedbacks?
>
> --
> Fábio Miranda Costa
> frontend@portalpadroes
> Globo.com
> *github:* fabiomcosta
> *twitter:* @fabiomiranda
> *ramal:* 6476
>
>
>
> On Wed, Jul 6, 2011 at 9:03 PM, Aaron Newton <[email protected]> wrote:
> > JSONP can't catch 400 errors because it's a callback system waiting for the
> > script to load. If the script fails, the callback is not invoked and so it
> > has no way of knowing that the script failed. The best it can do is be given
> > a timeout. If the request takes too long, or the script tag that is injected
> > fails to load, the timeout fires and you know it didn't load.
>
> > On Wed, Jul 6, 2011 at 2:22 PM, Rolf -nl <[email protected]> wrote:
>
> >> Working with some api that can return a bad request code 400 error
> >> with the error message as a response in json. Is there a way I can use
> >> it? Because the response contains useful information about wrongly
> >> used params? There's a failure event, but that works with the timeout
> >> and I that's not really usable or the same.

Reply via email to