0

For the jQuery AJAX calls (http://api.jquery.com/jQuery.getJSON/), we use the .fail() callback to log JavaScript errors.

However, it looks like the .fail() function also gets called, when a call is not yet finished, but aborted by leaving the website (tracking still works, however, since there is sometimes enough time such that window.onerror gets triggered).

Now, tracking an aborted AJAX request is NOT want we want. We want to find out if the request does work (i.e. respond) or not.

Is there a possibility to differentiate between "AJAX call aborted" and "AJAX call without response"?

Simon Ferndriger
  • 4,455
  • 6
  • 28
  • 53
  • duplicates http://stackoverflow.com/questions/4807572/jquery-ajax-error-handling-to-ignore-aborted http://stackoverflow.com/questions/14435679/jquery-aborting-ajax-will-trigger-done-or-fail – Lepidosteus Oct 23 '13 at 09:23
  • What is the second param of the `.fail()` callback at this point? I would expect it to be `abort`. – cmbuckley Oct 23 '13 at 09:25

1 Answers1

2

There is. The fail handler receives three arguments: jqXHR, textStatus, and errorThrown. For an aborted request, textStatus will be equal to "abort" so you can determine the cause with

$.getJSON(...).fail(function(xhr, status) { if (status == "abort") ... });

If you are interested in further filtering, other possible values are "notmodified", "error", "timeout" and "parsererror".

Jon
  • 428,835
  • 81
  • 738
  • 806
  • Now I have a question about the `"error"` textStatus. How does it get triggered, what does it mean. And how to I find out what the error is? Do I need a third parameter in the .fail callback here? – Simon Ferndriger Oct 23 '13 at 09:45
  • 1
    @SimonFerndriger: It means that the request did not get through or that the server returned an HTTP response code in the 4xx or 5xx range. I have never found practical use for it; if you want to see what happened you are much better off checking [`xhr.readyState`](http://stackoverflow.com/questions/632774/what-do-the-different-readystates-in-xmlhttprequest-mean-and-how-can-i-use-them) and `xhr.status` (the HTTP response code or 0 if it didn't manage to get a response). – Jon Oct 23 '13 at 09:53
  • OK, thanks. Actually I don't have any use for the jQuery `error` after your explanation either. However, `xhr.readyState` sounds interesting. Is it possible to differentiate between **request did not get through** (due to client) and **reponse is a 4xx or 5xx** (due to server)? – Simon Ferndriger Nov 04 '13 at 13:16
  • OK, sorry, my question was not properly put. So, it is not possible to know when a request does **not** reach `readyState 4`, if it is due to a *client* or *server* problem - in the case of the mysterious `"error"`? And **if** a request reaches readyState 4, the `xhr.status` is all I need to read, while the `.fail()` will not be triggered? – Simon Ferndriger Nov 04 '13 at 13:37
  • Or in other words: the `"error"` textStatus is either already covered by a non `200 xhr.status` (server problem 4xx/5xx) **-OR-** if the request did not get through (but was obviously not aborted, because there is a particular textStatus for this error), there must be a serious and unlikey problem with sending the ajax request in the first place (like having a faulty browser or similar)? – Simon Ferndriger Nov 04 '13 at 14:05
  • 1
    @SimonFerndriger: I really don't know what you are trying to do, but you are needlessly complicating things for sure. If you don't abort and the request does not reach state 4 then you didn't manage to get an answer (*any* answer). That should be all you need to know. `fail` will be triggered both in this case and in the case where you do get an answer but it comes with an error code. If you specify both `done` and `fail`, one of them will always be triggered. – Jon Nov 04 '13 at 15:32
  • You might be right. All I wanted to do is to find out which errors should interest us in the sense of something went really wrong and ignore all other errors which are only fired due to the user aborted the request somehow. So what I do know is to log every `xhr.status` other than `200` (in case the request got through), and also all errors with the `.fail()` callback additionally, except `abort` and `error`, since somehow these errors seem not our (or the servers) fault... Sorry for complicating it up, I hope this made the situation more understandable. – Simon Ferndriger Nov 06 '13 at 09:02