Opened 11 years ago

Closed 4 years ago

#6814 closed defect (fixed)

Error in "load" callback triggers "error" callback even though xhr request was successful.

Reported by: guest Owned by: Bryan Forbes
Priority: high Milestone: 1.8
Component: IO Version: 1.1.0
Keywords: xhr, error, callback Cc: attila.lendvai, justin.driscoll@…
Blocked By: Blocking:

Description

Dojo 1.1.1 Rev 13707

If an error is thrown within the "load" callback function (after a successful request/response) when calling "dojo.xhrPost", the "error" callback is executed. The "error" callback should only be called due to an error with the request.

Justin Driscoll

Change History (9)

comment:1 Changed 11 years ago by James Burke

This has come up before in a different context. The issue is this:

We do not want a thrown JS error in the load callback stopping JS execution. Otherwise, other inflight XHR calls may not be processed correctly, since a queue is used to track outstanding XHR calls, and the thrown error would stop the queue processing.

That said, it would be nice to get an error with a stack trace to find the origin of the error, but then I can also see the desire to catch those sorts of errors and handle them via something like the error callback.

I do not have a good answer yet for this, but just documenting the previous context of this issue.

comment:2 Changed 11 years ago by guest

That makes sense that you don't want to kill off all other xhr requests but this behavior isn't documented anywhere I've found and could cause problems when your error callback assumes the request failed (client UI and server falling out of sync, etc.). Right now I'm checking the response status code within my error callback to confirm the error was request related but I had to find this out the hard way. Architectural issues aside I still believe that ideally the error callback would only be called on a failed request. Thanks for the info.

Justin Driscoll

comment:3 Changed 11 years ago by James Burke

Milestone: future

This should be somewhat addressed by #6863: now if djConfig.isDebug is true, the exception is not caught but bubbles out. For isDebug false/undefined, the error callback is called, and the error is logged to console.error.

This is probably as good as it gets for this issue until Dojo 2.0 where we could consider breaking out transport errors from callback logic errors. We need to give a way for the user's code to handle both, but if you want to distinguish between the cases, then we likely will need API changes.

comment:4 Changed 10 years ago by attila.lendvai

argh, i can't add myself to the CC after all the trouble of registering?

anyways... it's also biting me. i don't know how to differentiate between a random broken script being eval'd and a network error.

this is crucial, if for nothing else then for meaningful feedback for the user.

comment:5 Changed 10 years ago by bill

Cc: attila.lendvai added

comment:6 Changed 10 years ago by James Burke

I believe it should be possible to get network error info, at least as far as an HTTP 500 or 401, by checking the ioArgs.xhr.status. For example, an error: function for an XHR call:

error: function (response, ioArgs) {
    if (ioArgs.xhr.status === 500) {
        //bad server response.    
    }
}

comment:7 Changed 9 years ago by Chris Mitchell

Owner: anonymous deleted

comment:8 Changed 7 years ago by bill

Component: GeneralIO
Owner: set to Bryan Forbes

You can close this if it's addressed in dojo/request.

comment:9 Changed 4 years ago by dylan

Milestone: future1.8
Resolution: fixed
Status: newclosed

Fixed with dojo/request.

Note: See TracTickets for help on using tickets.