[dojo-contributors] Instrumenting deferreds to log (unhandled) rejection values

Kitson Kelly kitson.kelly at asseverate.co.uk
Mon Jun 11 02:54:41 EDT 2012


Yes, based on the conversation we had yesterday, I think the stack traces
would be useful.

Also, I think we should standardise on "debug" output with dojo/has and
that like dojo/error, we should potentially consider standardising on on
some sort of instrumentation that isn't only for promises, but potentially
other areas.  Like for example dojo/debug and then it would make it quite
easy for us to develop around that.  I know "isDebug" config option has
sort of dwindled to basically some output of some of the kernel log
messages, but I think there is an opportunity to build something that is
more meaningful around more "modern" Dojo concepts.

On 10 June 2012 23:14, Mark Wubben <mark at novemberborn.net> wrote:

> I've been thinking about this some more.
>
> It'd be preferable if instrumentation was enabled by default during
> development, but disabled in the build output. I.e. enable it unless a
> has-flag is set disabling instrumentation, and make sure that flag is set
> statically in the build profile.
>
> I'd prefer the unhandled-rejections strategy to be the default, as it cuts
> down on needless logs in favor of logging just those errors that are not
> handled anywhere.
>
> It should also be possible under Chrome [1] to expose stack traces of
> where a deferred is instantiated. This will make the error logs more
> useful. Q [2] supports this.
>
> Thoughts?
>
> [1]: http://code.google.com/p/v8/wiki/JavaScriptStackTraceApi
> [2]: https://github.com/kriskowal/q/
>
>
> On 7 Jun 2012, at 09:12, Ken Benjamin wrote:
>
> > I'll echo Mike's comment about uncaught errors and unaware devs.
> >
> > Arriving as a dojo newbie 6 months ago the whole idea of Deferreds was
> new
> > territory for me and even though the errors thrown are often nearly
> > useless in debugging at least you know you broke something since the last
> > time you ran your app.
> >
> > I'm still not sure where all the possible errors I might need to handle
> > are, though I'm getting sufficiently knowledgeable to start to figure
> that
> > out now.
> >
> > My preference would be for an option to turn the error logging off but
> > leave it on by default.
> >
> > Improved messages that actually show the line where the Deferred was
> > called from would be nice, if possible.
> >
> > Ken Benjamin
> > http://wisdomwebsite.com
> > kenbenjamin at kenbenjamin.net
> >
> >
> >
> >
> > -----Original Message-----
> > From: dojo-contributors-bounces at mail.dojotoolkit.org
> > [mailto:dojo-contributors-bounces at mail.dojotoolkit.org] On Behalf Of
> Mike
> > Wilcox
> > Sent: Thursday, June 07, 2012 1:27 AM
> > To: dojo dev.
> > Subject: Re: [dojo-contributors] Instrumenting deferreds to log
> > (unhandled) rejection values
> >
> > It's awesome that you are moving forward on this.
> >
> > I am concerned that you would have to go through a lot of effort and have
> > a lot of knowledge to get Deferreds to throw uncaught errors - it would
> > still catch unaware devs off guard.
> >
> > I've been playing with this today, and I inserted this line in
> > Deferred.then:
> >
> > errback = errback || function(e){ console.error('uncaught error in
> > deferred:', e); }
> >
> > This works well, except that it throws multiple times in a chain, so it's
> > not perfect.
> >
> > Mike Wilcox
> > http://clubajax.org
> > mike at mikewilcox.net
> >
> >
> >
> > On Jun 6, 2012, at 5:49 PM, Mark Wubben wrote:
> >
> >> 1.7 supported `config.deferredOnError` which would be called with the
> > error value for every rejected deferred. If not configured
> > `console.error()` would be used instead. I removed this from
> > `dojo/_base/Deferred` with the new promise API in 1.8.
> >>
> >> This means there is no clear way of noticing errors, other than your
> > code not working as expected. LiuCougar pointed out he was actually using
> > `config.deferredOnError` to report errors to the server.
> >>
> >> The naive implementation in 1.7 logs all rejection values, assuming they
> > are actually code errors. That's not necessarily true, I often
> > intentionally throw errors in my own code to communicate a failure state.
> > I tried to find a middle ground with `instrumentRejected`, see
> > <
> https://github.com/novemberborn/dojo/commit/0fffe22cf97504c90e45cd521cf2c
> > 4b504e65e5d>.
> >>
> >> Depending on a has() test (for the `deferredEnableInstrumentation`
> > config flag), `Deferred.instrumentRejected()` is called (if specified)
> > with the error value and whether a listener was registered for it.
> > `dojo/promise/instrumenting` can set up default reporters. Either to
> > immediately log the error (1.7 behavior) or to detect unhandled errors
> > after a short interval. These are useful during development, you'd want
> to
> > roll your own to log unhandled errors in production. See
> > <https://gist.github.com/14c8266d22444dc6f030>.
> >>
> >> Question 1: Is this a useful approach?
> >>
> >> Question 2: How do we get this enabled by default during development?
> >>
> >> Cheers,
> >>
> >> --
> >> Mark Wubben
> >>
> >> http://novemberborn.net
> >> http://twitter.com/novemberborn
> >>
> >> _______________________________________________
> >> dojo-contributors mailing list
> >> dojo-contributors at mail.dojotoolkit.org
> >> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> >
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors at mail.dojotoolkit.org
> > http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors at mail.dojotoolkit.org
> > http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>
> --
> Mark Wubben
>
> http://novemberborn.net
> http://twitter.com/novemberborn
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20120611/4d3194f4/attachment-0001.htm 


More information about the dojo-contributors mailing list