Opened 7 years ago
Closed 7 years ago
#15662 closed defect (worksforme)
factory errors swallowed
Reported by: | bill | Owned by: | Rawld Gill |
---|---|---|---|
Priority: | undecided | Milestone: | tbd |
Component: | Loader | Version: | 1.7.3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description
I've noticed that errors during initialization are swallowed. Saw this from running dijit/tests/mobile.html when (due to some local changes I had made) dojo.declare() threw an error. See attached test case if necessary.
In the test case, the last dependency to load (at least on my machine) is Menu.html, which of course is loaded via getText(), which for some reason is still using dojo/_base/xhr. After that finishes, the loader starts calling factories, and one of the factories get's an exception from dojo.declare().
err (declare.js:8) c3mro (declare.js:74) declare (declare.js:943) (anonymous function) (DropDownButton.js:17) runFactory (dojo.js:1055) execModule (dojo.js:1184) execModule (dojo.js:1175) execModule (dojo.js:1175) checkComplete (dojo.js:1207) onLoad (dojo.js:1264) load.finish (text.js:184) load (text.js:201) dojo._ioSetArgs.err (xhr.js:415) notify (Deferred.js:187) complete (Deferred.js:168) dojo.Deferred.resolve.callback (Deferred.js:215) notify (Deferred.js:196) complete (Deferred.js:168) dojo.Deferred.resolve.callback (Deferred.js:215) dojo.xhr.rDfd.then.otherwise.ioArgs.error (xhr.js:658) signalListener (Deferred.js:36) signalWaiting (Deferred.js:27) Deferred.resolve (Deferred.js:168) signalDeferred (Deferred.js:74) signalListener (Deferred.js:46) signalWaiting (Deferred.js:27) Deferred.resolve (Deferred.js:168) signalDeferred (Deferred.js:74) signalListener (Deferred.js:51) signalWaiting (Deferred.js:27) Deferred.resolve (Deferred.js:168) signalDeferred (Deferred.js:74) signalListener (Deferred.js:46) signalWaiting (Deferred.js:27) Deferred.resolve (Deferred.js:168) handleResponse (xhr.js:48) onLoad (xhr.js:74)
Perhaps it's just that runFactory() should be surround by a try/catch and a console.error()?
Maybe you are intentionally not catching the error so that firebug will break on where the error occurs, aka so "break on uncaught exceptions" works? The problem is that firebug doesn't tell me anything.
Attachments (1)
Change History (4)
Changed 7 years ago by
Attachment: | factoryError.patch added |
---|
comment:1 follow-up: 2 Changed 7 years ago by
I filed #15663 about a change in dojo.xhr()'s behavior that is causing part of the problem, although probably not all of it.
What about when a factory throws an error and dojo/text! is not being used, so that runFactory() is being called from the onload callback of a <script> tag? I didn't try it, but I suspect the error gets swallowed then too.
comment:2 Changed 7 years ago by
Replying to bill:
I filed #15663 about a change in dojo.xhr()'s behavior that is causing part of the problem, although probably not all of it.
What about when a factory throws an error and dojo/text! is not being used, so that runFactory() is being called from the onload callback of a <script> tag? I didn't try it, but I suspect the error gets swallowed then too.
I think you can get the effect you are looking for by setting the has feature "config-dojo-loader-catches" to true in dojoConfig. fyi, the factory code looks like this: http://bugs.dojotoolkit.org/browser/dojo/dojo/trunk/dojo.js#L1078
Let me know how this works for you.
comment:3 Changed 7 years ago by
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Actually, factory errors are being reported for me, even without setting that "config-dojo-loader-catches" flag. (TBH, I'm not sure how to set a has() flag in dojoConfig.) So I'll close this... the only issue seems to be #15663.
I'm not sure why you have that "config-dojo-loader-catches" flag though, it seems like you would always want to report errors from the factory.
unreduced test case, apply this patch against [29194] and then run dijit/tests/mobile.html