Opened 12 years ago
Closed 7 years ago
#11568 closed defect (wontfix)
[patch][ccla]XHR attribute "failOk" isn't surpressing all error messages
Reported by: | James Thomas | Owned by: | Bryan Forbes |
---|---|---|---|
Priority: | high | Milestone: | 1.11 |
Component: | IO | Version: | 1.5 |
Keywords: | xhr | Cc: | |
Blocked By: | Blocking: |
Description
According to the latest API docs for dojo.xhrGet, the "failOk" attribute "indicates whether a request should be allowed to fail (and therefore no console error message in the event of a failure)"
Using the following test code.
var hostUrl = "http://localhost/a_url_to_generate_a_404"; var args = {failOk:false, url:hostUrl}; dojo.xhrGet(args);
I can see two error messages getting logged to the console when this request fails.
Error: Unable to load http://localhost/a_url_to_generate_a_404 status:404 Error: Unable to load http://localhost/a_url_to_generate_a_404 status:404
If I then "failOk:true" and re-issue the request, I still get one of the error messages.
Error: Unable to load http://localhost/a_url_to_generate_a_404 status:404
Looking through the code and there's a check for dfd.ioArgs.args.failOk in _deferError from xhr.js. However, the second error log is being generated in Deferred.errback in this code.
if(!error || error.log !== false){ (dojo.config.deferredOnError || function(x){ console.error(x); })(error); }
The Error object being generated when the xhr request fails doesn't set the appropriate error.log value to suppress the deferred error messages.
Attachments (1)
Change History (7)
Changed 12 years ago by
Attachment: | failok.patch added |
---|
comment:1 Changed 12 years ago by
Owner: | changed from anonymous to James Burke |
---|
comment:2 Changed 12 years ago by
Summary: | Dojo XHR attribute "failOk" isn't surpressing all error messages → [patch][ccla]XHR attribute "failOk" isn't surpressing all error messages |
---|
comment:3 Changed 10 years ago by
Component: | Core → IO |
---|---|
Owner: | changed from James Burke to Bryan Forbes |
Status: | new → assigned |
Probably this will be fixed with dojo/request, assigning to Bryan.
comment:6 Changed 7 years ago by
Milestone: | tbd → 1.11 |
---|---|
Resolution: | → wontfix |
Status: | assigned → closed |
This isn't relevant in the context of dojo/request, as it just provides promise callback and errback handlers rather than this sort of mechanism. Marking as wontfix.
fix from James Thomas (IBM, CCLA)