Opened 11 years ago

Closed 11 years ago

#6821 closed enhancement (fixed)

Preserve exception information in dojo.xhr

Reported by: Adam Peller Owned by: James Burke
Priority: high Milestone: 1.2
Component: IO Version: 1.1.0
Keywords: Cc:
Blocked By: Blocking:

Description

In dojo.xhr, when an exception is encountered, the deferred object is canceled

		try{
			xhr.send(ioArgs.query);
		}catch(e){
			dfd.cancel();
		}

It would be nice if the exception were somehow preserved in the callback, perhaps passed and reused as or wrapped in the Error object.

Deferred.cancel() doesn't seem to take an argument, and I don't know if it should. The alternative would be to stuff the error in the deferred object somewhere and dig it out in the _deferredCancel method, then pass it back to the callback function.

Can more information be passed in the Error object, like the xhr object?

Also, off topic, should the squelch in cancelAll be inside the loop so one error doesn't abort the iterator?

	dojo._ioCancelAll = function(){
		//summary: Cancels all pending IO requests, regardless of IO type
		//(xhr, script, iframe).
		try{
			_d.forEach(_inFlight, function(i){
				i.dfd.cancel();
			});
		}catch(e){/*squelch*/}
	}

Attachments (1)

testXhrGet.html (1.4 KB) - added by Adam Peller 11 years ago.
test case from Jim Patrick, IBM (CCLA)

Download all attachments as: .zip

Change History (4)

comment:1 Changed 11 years ago by James Burke

Milestone: 1.2

Adam: do you have a test case I can use to duplicate an error on xhr.send?

I tried using an url like "xhr:foo", but that fails in the xhr.open call. I tried calling an URL that does not exist on the server, like url: "/foo", but that goes through the normal error handler for a 404. For doing an xdomain call, I get a security exception, in the console, but no callbacks.

I think we can pass a better error back in the case you describe, but I want to be sure I can test the change.

Also, on the dojo._ioCancelAll question on if there should be a try/catch: that function is only called in the IE addOnUnload case to do cleanup. Since it happens in the unload process, I think it is fine if we put in the try/catch, and do not worry about bubbling out the exception (like for the djConfig.isDebug case).

I can do that change when I can test the xhr.send thing.

Changed 11 years ago by Adam Peller

Attachment: testXhrGet.html added

test case from Jim Patrick, IBM (CCLA)

comment:2 Changed 11 years ago by Adam Peller

The test case I was given (see testXhrGet.html) is a simple xhr, in a situation where the network connection suddenly disappears between page load and the user clicking on the link. The developer would like to get at the exception object for more info. Now all that's available is the Error object with "xhr cancelled"

comment:3 Changed 11 years ago by James Burke

Resolution: fixed
Status: newclosed

(In [14319]) Fixes #6821: Preserve exception info in case where xhr.send fails. The original exception is accessible off the response.cancelResult property inside the handle(response, ioArgs) callback.

Note: See TracTickets for help on using tickets.