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

Mark Wubben mark at novemberborn.net
Sun Jun 10 18:14:43 EDT 2012


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



More information about the dojo-contributors mailing list