[dojo-contributors] Promises

James Burke jburke at dojotoolkit.org
Fri Mar 5 00:07:39 EST 2010


On Thu, Mar 4, 2010 at 5:57 PM, Eugene Lazutkin <eugene at lazutkin.com> wrote:
> If it is 100% backwards compatible yet smaller --- I am all for it. But
> setTimeout() hack bums me out. It is bad on so many levels including
> debugging. And throwing an error from a setTimeout() callback... What is
> the grand idea anyway? Who is going to catch it? How to catch it? Why
> bother? How can it help me to find the source of an error? Why not
> console.log() an error --- the effect looks similar? Why is this a good
> way to do the default error processing?

I was thinking of something similar to what Eugene mentions in his
post, allow for a default error handler to be configured,
dojo.Deferred.defaultErrback or some name, and pass it enough info so
that it can decide what to do with the error, but only call the
default error handler if there is not already a registered error
handler. During dev time, (maybe via a djConfig switch), a default dev
error handler would just throw all the time to allow stack tracing.
Non-dev time (no djConfig switch), no default error handler is passed.

If the user wanted to special case that default error handler to only
throw in some cases, then they could swap in their own default
handler.

Hopefully, the default error handler could get enough info so that if
you wanted to implement a setTimeout-based one, it would still work.
But I think for debugging purposes for stacks the default one we would
configure via a djConfig switch would just throw immediately. With
that approach we could remove the setTimeout dependency in the normal
code, and at least with the current patch, a console dependency too.

What I am not sure about:
- Will that sort of setup violate the ocap goals? At first look I
think it is OK, but I am still new to the code and ocap requirements.
- the reject function right now can take a second arg, dontThrow. How
does that work, what are the use cases for that, or is it there mostly
to help with this sort of error handling for dev/debug cases, not to
throw if the caller of reject knows it is not serious?

James


More information about the dojo-contributors mailing list