To the best that I can discern, Domains is referring to attaching "error" handlers to the process or a domain (which handle *un*caught errors), and the *solution* is `catch`ing and appropriately handling the Error. If a thrown Error has been caught by `process`, that means no user code couldn't have possibly responded to it appropriately, and (for an HTTP request) there's going to be an open TCP connection sitting around in memory. Note that there are many ways to leak objects in your process, uncaught errors are just one of them.
Shutting down the process is the safe way to respond to these uncaught errors, and `uncaughtException` is provided so you can do this appropriately. This isn't a strategy to fix your code, it just indicates your code is broken somewhere: spinning up the process is deliberately the most expensive part of Node.js and an easy source of DOS attacks. Additionally, your database and anything else you write to may now be in an undefined state - restarting the process doesn't fix this. Austin. On Friday, August 30, 2013 10:16:21 AM UTC-7, 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 > -- -- 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.
