This all are good arguments, in the theory ... in praxis, I think:
1. Most developers do not assume async/sync mixed styles today ...
2. That kind of performance overhead matters in some rare cases, I think ...
normally you don't care about 10-15ms ... If the overhead is much higher its
about the overall process load ... even if you get your callback faster, some
other parts of the application will wait. At the end the whole application will
perform at the same speed ... no?
3. This is one of nodejs very bad parts which should be possibly solved on some
other level, saving stacks over X loops ... or whatever .... All the
longstacktraces modules I have tried have consumed huge amount of memory so its
not for production.
Oleg
> I think using nextTick() for error handling is a very very bad idea.
>
> Stack trace could be very helpful when error happens. use nextTick basically
> throws that stack trace ability away.
>
> Moreover, the whole nextTick thing is stupid IMO. When I use an asynchronous
> API, I always assume it *may* be optimized for some cases to run
> synchronously. So changing the state of a callback function between it is
> used and it is called is a very very bad idea. In almost every case I ran
> into, it turned out to be a programmer mistake rather than an intended
> behavior. The programmer should *NOT* assume a guaranteed execution order. It
> is a very unnecessary overhead (sometimes also very large) to pay for API
> developers just to guarantee execution order, because execution order is
> irrelevant in most cases.
>
> To sum up,
> 1) Programmer should assume an asynchronous API may callback synchronously
> because of optimization for some fast path.
> 2) Guarantee execution order of a callback is unnecessary in most cases, so
> it's an overhead that should be avoided by default.
> 3) Definitely DO NOT use nextTick for error handling code, because it throws
> away the stack information for nothing.
>
> -Chaoran
>
> On Tuesday, August 20, 2013 12:47:22 PM UTC-5, Bryan Donovan wrote:
> I have been writing node.js client code for a couple of years now, and have
> authored a couple open source libraries, but somehow I missed the memo
> telling me that I'm supposed to wrap 'synchrounous' callbacks in
> process.nextTick(). I kind-of understand why that is a best-practice, but
> what I don't understand is what the drawback is if you don't do it.
>
> For example, I write code like this all the time, and have never had a single
> problem with it:
>
> function getSomething(args, cb) {
> if (!args) { return cb(new Error('args required')); }
> if (!args.id) { return cb(new Error('args.id required')); }
>
> SomeDatabase.get({id: args.id}, cb);
> }
>
> What are the potential issues with not wrapping those arg checks in
> process.nextTick()?
>
>
> Thanks,
>
> Bryan
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> 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 post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> 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 [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
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 post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
