>
>
> On Friday, August 23, 2013 10:21:37 AM UTC-5, Oleg Slobodskoi wrote:
> This all are good arguments, in the theory ... in praxis, I think:
>
> 1. Most developers do not assume async/sync mixed styles today ...
>
> In practice, coding standard should not be lower because of programmer
> laziness, right?
Depends on how much pain it causes ... If official nodejs doc warns people then
its probably fine ...
>
> 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?
>
> Yes, the overhead matters only in rare cases. But imagine you're writing an
> API that unfortunately falls into that rare case, what would you do? Do you
> use nextTick to pay that unnecessary and large overhead, or do you use invoke
> callback synchronously and add a "CAUTION" in your doc to warn programmers?
> Both ways are too inelegant IMO. I think the best way to go would be
> educating programmers to assume all asynchronous calls may be executed
> synchronously, that way nobody will need to pay the unnecessary overhead
> (it's a big deal for whose who fall into that rare cases!), and no need to
> warn your user in the doc.
I have never seen such cases ... and can't imagine them ... but potentially yes
...
>
> 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.
>
> I don't think it's nodejs's bad. It's bad programming principle. Throw away
> your stack information just to guarantee execution order when the user in
> most cases might not need at all? Seriously?
>
> IMO It can be solved very easily. Just don't use nextTick for error handling
> code. Period.
stack trace problem is there independent of the topic ... you are using lots of
real async apis which WILL drop your stack trace ....
>
>
> 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.
