Application-level errors are dispatched to the onerror handler

[jsilland]

As per http://stackoverflow.com/questions/10584318/when-should-xmlhttprequests-onerror-handler-fire, the onerror handler for XHRs is called when there is an issue at the transport level (e.g. no route between the host and the remote). On the other hand,onload is otherwise called if the server returns a correctly formed response. This is also the commonly observed behavior in browsers: see the following snippet and try to run it in your browser's console:

x = new XMLHttpRequest();
x.onload = function() {console.log('onload')};
x.onerror = function() {console.log('onerror')};
x.open('GET', '/something that does not exist');
// Calling x.send() will call the onload handler will be called and the response's status is 404

I've tested this on Chrome, Safari and Firefox. In this library's emulation of XHRs, however, the onerror is called for any response that is not in the 2xx range — with the code under test looking like the setup above and test code such as:

jasmine.Ajax.stubRequest('/something that does not exist').andReturn({status: 404})
x.send();

Further assertions based on assumption that the onload handler will have been called are failing.

Why can't I use onreadystatechange like a regular person? I'm using a onload and onerror because they allow me to Promise-ify my XHR code — I can call resolve from onload and reject from within onerror with a mostly direct semantical mapping.

I'm happy to provide a full test-case if you think this is something worth addressing —

[slackersoft]

Sounds like we are doing something that doesn't match the spec. When in doubt, we would definitely like Jasmine-Ajax to match the spec. We would be happy to review a pull request that causes onerror and onload to fire under the correct circumstances.