[dojo-contributors] Promises

Eugene Lazutkin eugene at lazutkin.com
Fri Mar 5 13:14:25 EST 2010

Hash: SHA1

Obvious +1 --- djConfig is the absolutely right place to specify the
initial error processing.


On 3/5/10 12:05 PM, James Burke wrote:
> 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.
> James
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the dojo-contributors mailing list