javascript callback guard - prevents a callback to be called twice

已查看 273 次
跳至第一个未读帖子

Simon Doodkin

未读,
2014年8月19日 16:18:302014/8/19
收件人 nod...@googlegroups.com
Not long ago, T.J. complained in an article that he doesn't likes that in node.js sometimes callbacks are called more than once.
i have a simple solution for this if you need it. also i can suggest that if you have callback problems you could use https://github.com/mattinsler/longjohn module to trace the problem. id did it several times.

cbguard:  https://gist.github.com/shimondoodkin/a6762d8ab29ea497e245

// cbguard by Shimon Doodkin - license: public domain
 
function cbguard(cb,printerr){ //kind of filter for callbacks. it prevents a callback to be called twice
var cb1=cb;
return function() {
if(cb1) { var cb2=cb1; cb1=false; return cb2.apply(this,arguments); }
else if(printerr)console.log(new Error('cb called twice').stack);
}
}
 
// usage example:
//function myfunction(cb)
//{
// cb=cbguard(cb); // usage example
// // or
// // cb=cbguard(cb,true); // good when developing, it will protect and also tell you you have a problem, here a callback is called twice here.
//
// things that are based on event emitteres are usually have problems with multiple callbacks.
 

Alexey Petrushin

未读,
2014年8月21日 14:24:442014/8/21
收件人 nod...@googlegroups.com
In my understanding the problem is not that it's not possible to prevent callback from being called twice, with underscore it's as simple as `cb = _(cb).once()` - but the problem is that it's cumbersome to do it everywhere.

Ω Alisson

未读,
2014年8月22日 04:35:292014/8/22
收件人 nod...@googlegroups.com
How do people stumble upon this kind of error?


--
Job board: http://jobs.nodejs.org/
New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md
Old group rules: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/0bfddd86-2dfd-4e35-a3a4-72c323e739b7%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

zladuric

未读,
2014年8月22日 07:51:032014/8/22
收件人 nod...@googlegroups.com

On Friday, August 22, 2014 10:35:29 AM UTC+2, Alisson Cavalcante Agiani wrote:
How do people stumble upon this kind of error?


When you have long and tricky business logic. Ie. I am bidding on a product. Make CC authorization. Is it ok? Yes? Go book a product. Did somebody in the mean time buy the last one? Remove authorization, or if all ok, proceed. What about if my authorization fails? What if I have a retry logic on the warehouse check methods because it's unstable?

This can be avoided by not having long methods, having smart architecture, but sometimes you inherit messy code, or write it yourself, and you have a long long method with multiple possible paths, and in only one of those you have to call back.

 

Simon Doodkin

未读,
2014年8月23日 11:30:582014/8/23
收件人 nod...@googlegroups.com
people usually try to add a callback add on to an EventEmitter
usually thinking to themselves there will be only one error but usually there are several together, usually:
on connection error, on write closed connection, on connection timeout, they all come together.

https://gist.github.com/shimondoodkin/5718436#file-1-callback-basics-tutorial-js-L67

Alexey Petrushin

未读,
2014年8月23日 16:34:272014/8/23
收件人 nod...@googlegroups.com
Usually such errors are tiny and non critical, unless you can start to see it when you need to build something complex that works reliably.

I didn't experienced any problem with node.js for couple of projects (also, I use Fibers and don't have any problems with asynchronous issues at all). 

Until the recent project - web crawler distribute over bunch of machines. In my cases it happened in the following scenario - everything works nice, and you deploy it. And after half a day half of machines becomes zombie. And you start to searching for this sort of tiny problems (also another pain in the ass - if sometimes, rarely, some vendor library throws unhandled exception you can't intercept and properly destroy something). 

It's very hard to deal with, such bugs can easily take 30% of development time, it's especially complex because it's very hard to reproduce.
回复全部
回复作者
转发
0 个新帖子