[dojo-contributors] Promises

James Burke jburke at dojotoolkit.org
Fri Mar 5 13:05:04 EST 2010

On Fri, Mar 5, 2010 at 5:57 AM, Kris Zyp <kzyp at dojotoolkit.org> wrote:
> After thinking about this more, I am probably being a little too
> pedantic in pursuing semantic purity. I think you are right Eugene,
> simply doing a console.error for every error as a default action that
> can overriden is fine behavior for the majority of applications, gives
> good error visibilty, and those that need to suppress the error logging
> can, and removing the logic (the setTimeout and error tracing) to detect
> uncaught errors actually saves a few dozen bytes. I uploaded new version
> to the ticket, do you want check to see if this is adequate:
> http://bugs.dojotoolkit.org/attachment/ticket/10814/Deferred.js#L80
> Does this sound good to everyone?

I prefer to configure the onError via a djConfig value:

dojo.Deferred.onError = dojo.config.deferredOnError;

then only call dojo.Deferred.onError if it has a value (assumed to be
a function).

Having it as a djConfig value allows setting it before the layer
containing Deferred is loaded, which can be important if the layer
does some automatic Deferred usage.

if djConfig.isDebug is set to true, then perhaps we automatically set
the onError to console.error (if djConfig is not already specifying a
value). We can do that auto-set where the isDebug setting happens. If
someone wants stack tracing of errors, they can set
djConfig.deferredOnError = function(e) { throw e;};

That way we keep a console dependency outside of the Deferred module,
and only active during debug setting? I am happy to do the djConfig
wiring if that helps.


More information about the dojo-contributors mailing list