Skip to main content

Bug Tracker

Side navigation

#11207 closed bug (invalid)

Opened January 23, 2012 02:23AM UTC

Closed February 07, 2012 08:27AM UTC

Last modified August 22, 2014 12:46PM UTC is not decremented on completion of AJAX request if an exception occurs in any deferred.done/fail callbacks

Reported by: Owned by:
Priority: undecided Milestone: None
Component: unfiled Version: 1.7.1
Keywords: Cc: jaubourg
Blocked by: Blocking:

The counter is not decremented after an AJAX request if an exception occurs in any attached deferred done/fail callbacks. This means the global error handlers do not fire from that point forward.

Tested in IE9, Chrome 16.0.912.75 and Firefox 9.0.1, Windows 7

Your retarded spam detection system won't let me lodge this ticket with a jsFiddle URL. Try jsFiddle Uhzae, or the following code:

$(document).ajaxError(function () {

// never fires...

alert("AJAX error occurred...");


$(function () {


url: '/nonexistent/url',

error: function () {

throw "manual error";




Attachments (0)
Change History (13)

Changed January 23, 2012 02:28AM UTC by rwaldron comment:1

owner: →
status: newpending

Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket!

Additionally, be sure to test against the "jQuery (edge)" version to ensure the issue still exists. To get you started, use this boilerplate:

Open the link and click to "Fork" (in the top menu) to begin.

Changed January 23, 2012 02:36AM UTC by anonymous comment:2

Replying to [comment:1 rwaldron]:

Thanks for taking the time to contribute to the jQuery project! Please provide a complete reduced test case on jsFiddle to help us assess your ticket!

Changed January 23, 2012 03:06AM UTC by rwaldron comment:3

resolution: → wontfix
status: pendingclosed

If you throw an error from within the error handler, there is no reasonable why for jQuery to handle that for you.

Changed January 23, 2012 03:17AM UTC by anonymous comment:4

Replying to [comment:3 rwaldron]:

If you throw an error from within the error handler, there is no reasonable why for jQuery to handle that for you.

This is not just from the error handler. This is from ANY deferred callback (done/fail/always) that could potentially be several "chained" deferreds down the track.

How about a try..finally block around where the deferred callbacks are executed that decrements the active counter appropriately?

You're telling me that you find it acceptable an unhandled exception anywhere in any callback from an AJAX request breaks jQuery by putting it in an inconsistent state? (active == 1 when there are no active requests).

I don't have time to submit a patch, but I would bet my life on it that there is an elegant way to achieve this.

Changed January 23, 2012 03:25AM UTC by rwaldron comment:5

resolution: wontfix
status: closedreopened

Sorry, I have a habit of writing highly tested, rigorously fuzzed, defensive code that won't throw exceptions and leave my program in an inconsistent state.

I'll re-open this and cc @jaubourg (author of the ajax and deferred modules) for his opinion

Changed January 23, 2012 03:26AM UTC by rwaldron comment:6

cc: → jaubourg

Changed January 23, 2012 03:35AM UTC by comment:7

Fair enough, but you can't tell me that you don't still get unhandled exceptions due to coding errors. Everyone makes mistakes, bugs DO get through to production systems, regardless of how "highly tested" and "rigorously fuzzed" the application is. An unhandled exception in an individual component does not mean the entire application is in an inconsistent state.

This issue means that the application cannot continue to operate until the page is refreshed, a pretty big issue in a single-page web application.

You're correct in that this has highlighted an issue in my application that requires addressing. The debugging experience to find the issue was... not whole lot of fun.

Thanks for the prompt attention anyways!

Changed January 23, 2012 03:58PM UTC by dmethvin comment:8

status: reopenedpending

I don't see how we can "fix" this without wrapping the handler in a try/catch, which prevents meaningful browser error messages from appearing. What code is expected to *catch* the error that you are throwing? The code is run asynchronously so there is none of your code on the stack that could process it meaningfully.

Changed January 23, 2012 04:39PM UTC by gibson042 comment:9

Just to be clear... there is an objection to the try..finally solution of comment:4, but only because a working implementation in IE<9 requires an intervening catch( x ) { throw x; } that hides the source/context of exceptions (as documented on #9033 at

Changed January 24, 2012 02:33AM UTC by Dale Anderson <> comment:10

Ahh, that's a pain with IE9, seemed a neat solution. It would be nice if there was some sort of inner exception, but wishful thinking. Playing around with the objects passed to the throw statement, you can almost get it to look the same, but it does still lose context.

Decrementing the active counter before firing deferred callbacks might work. It's a little messier, maintaining a flag to raise the ajaxStop event, but would avoid the issue in the ticket.

Changed February 07, 2012 08:27AM UTC by trac-o-bot comment:11

resolution: → invalid
status: pendingclosed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

Changed March 05, 2014 04:09PM UTC by comment:12

Hello, I guess I have similar problem. Is it possible to have it fixed? Getting proper number of active ajax connections, even when exception appears, is crucial for automated testing of my application.

Changed August 22, 2014 12:46PM UTC by Maralis_Daniel comment:13

Hello. Have problem on tests. Incorrect work of - it returns that there is 2 conections when all ajax operations are complite. Result of this is that tests executes forever. Please re-open this ticket and do something with this error.