claus.reinke at talk21.com
Fri Nov 9 13:57:09 PST 2012
>> Another idea: log such transformed errors, or automate matching of handled failed promises
>> against generated failed promises.
> What we really need, as mentioned by Kris Kowal on Twitter recently, is the ability to
> *un*-console.log something. That is, we want to log unhandled rejections for the duration of them
> being unhandled, but if someone does come along and handle it, we need to get it out of the
yep, that was the rough direction, though I'd use an explicit off-console
log buffer (which might then be visualized continuously or pulled occasionally
for console snapshots, similar to heap profiles).
> Currently we kind of do this by exploiting a trick in some browsers' array-logging capabilities.
> If you log an empty array, but later modify its contents, it live-updates in Chrome (although this
> behavior might be going away from what I can tell) and I believe other browsers. This is a bit
> hacky and unpredictably supported.
> All this has led us to contemplate building browser extensions with appropriate hooks for such
> logging. That's still an as-our-scarce-time-permits project, however.
If your time is scarce and your goals involve generally valuable tooling,
why not explain your needs on js-tools? I can't promise that there will
be takers for every project, but encouraging sharing of efforts was one
of the goals for establishing that mailing list.
Same holds for sharing debugging war stories from which needs and
opportunities for better tooling might be inferred: don't hide them here
were they aren't actionable (there was an example of memory leak
tracking recently on this list, iirc).
More information about the es-discuss