FWIW, the error issue is a strawman. You can/should use long-stack-traces for debugging/development, and trycatch ( https://github.com/CrabDude/trycatch/) for production, which avoids the need to both restart on domain errors ( http://nodejs.org/docs/latest/api/all.html#all_warning_don_t_ignore_errors) and the need to use domain.bind.
Cheers, Adam Crabtree On Thu, Aug 22, 2013 at 1:22 PM, Scott González <[email protected]>wrote: > > > > On Thu, Aug 22, 2013 at 4:02 PM, Eldar <[email protected]> wrote: > >> I am sorry, I had to write more detailed explanation of my above >> statements. >> >> *Postel low (Robustness principle)* >> >> You can have a look at wikipedia article about it >> http://en.wikipedia.org/wiki/Robustness_principle. >> It contains explanation about why the robustness principle is harmful and >> contains a link to the corresponding RFC. >> >> About browsers. I am not much aware history of browsers wars, but I am >> aware about >> HTML parsers and what a shit they are and heard about how much efforts it >> took to make >> all that quirk stuff be a standard. Although browsers had a greater >> excuse for that than a pure machine protocols. >> >> Finally, I personally suffered from "robustness" even within my *private* >> tool chain :) >> > > I'm sorry, but again, this is misguided. The complaint in that article is > that by being liberal, you're masking potential problems in the calling > code. The only potential problem comes from other API developers begin > inconsistent and allowing sometimes-sync callbacks. Whether you want to > believe it or not, forcing always sync is both the strict and liberal > implementation. It's strict because it guarantees a specific order. It's > liberal because it guarantees the caller can't write broken code. So > perhaps this isn't the robustness principle exactly, but the fact remains > that the safest thing for everyone is always async. > > *process.nextTick* >> * >> * >> Downsides of process.nextTick are >> >> 1) It is none-standard, not available in other environments and even >> can't be shimed (with promise of the same performance). >> > > We're talking about node. If you're writing a multi-environment module, > then all node standards are out. The standard already exists directly in > node core. The core team has publicly stated that you should force always > async in a thread I already linked to. > > 2) It has performance costs. Significant or not depends on your use case. >> > > It's quite rare for modules to actually have significant performance costs > based on forced async. It does happen, but very rarely. > > >> 3) It disables some use cases. >> > > This cannot be true. You cannot have a sometimes-async API which breaks > when not always async. > > -- > -- > 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. > -- Better a little with righteousness than much gain with injustice. Proverbs 16:8 -- -- 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.
