Thanks, appreciate the link. Seems like the key part is at the bottom: Node is for running JavaScript, so JavaScript's limitations are Node program limitations. *JavaScript* throws are fundamentally unsafe if they jump over a branch in the execution-flow graph...
So I'm wagering that the catches in Node core as safe b/c they are adhering to safe rules regarding how they are structured in execution flow. On Friday, August 30, 2013 1:10:44 PM UTC-7, John C wrote: > > On Friday, August 30, 2013 11:16:21 AM UTC-6, Peter Skirko wrote: > >> Hi, >> >> I am trying to understand when it is safe to catch errors in node.js >> code, by which I mean both node.js core and userland code as well. >> >> According to http://nodejs.org/api/domain.html, >> >> "By the very nature of how throw works in JavaScript, there is almost >> never any way to safely "pick up where you left off", without leaking >> references, or creating some other sort of undefined brittle state. The >> safest way to respond to a thrown error is to shut down the process." >> >> Thus a naive rule is "Don't catch errors in your code. If you see an >> error, shut down the process after some mild cleanup (restart via cluster >> or equivalent process watcher). And don't use other code that catches >> exceptions either, by the same reasoning." >> >> However, grepping in the node.js core, I find that it uses catch in quite >> a few situations. Here's just one example, from lib/fs.js: >> >> fs.existsSync = function(path) { >> try { >> nullCheck(path); >> binding.stat(pathModule._makeLong(path)); >> return true; >> } catch (e) { >> return false; >> } >> }; >> >> As someone who is not steeped deeply in node.js on a daily basis, I have >> no way of understanding how the core can catch errors (> 30 locations with >> a simple grep) without leaking references or creating brittle state. >> Naively, if it followed the "domain rule", it should be exception neutral >> and propagate all exceptions upward so that the process can fail. >> >> Is there some way, like a rule of thumb or such, whereby I can determine >> that the core is in fact safe? It's just not clear to a casual observer, >> but seems deeply important for building robust node processes. I also don't >> want to just say to myself "it's in the core therefore it must be safe", >> b/c if that's not true, then I put production code at risk for unexpected >> issues. >> >> Any help would be appreciated, thanks in advance! >> >> -Peter >> > > There is some discussion in this post: > https://groups.google.com/d/topic/nodejs/4TYtu_xnNJY/discussion > -- -- 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.
