Hi Daniel, I'm going to answer even if I'm sure other people may be more knowledgeable than me on this subject.
If you take a step back, you would want to close your process whenever is goes in some inconsistent or unstable state. For example, if your app serves requests, you will want to terminate the process when the app cannot 'correctly' serve requests anymore but a restart will make it work again. Here, 'correctly' depends on the implementation of your application. Issues can come from a lot of origins and you should plan for all of them to happen (hardware, network, third party API changes, etc.). More precisely, always terminate the process on 'uncaught exception' for both process and domain APIs. Another example that comes to my mind is this. Let's say your application uses a database 'driver/module'. When the database connection is lost, the module throws an exception but expects you to retry to connect to the DB. If you don't have a retry mechanism built into your app, you may want to restart the process so that it connects again. It's a poor man's resiliency mechanism but it may work. The general guideline that I keep is that I want the application to keep working for the end users, whatever happens. It's always a matter of the time you have to build resiliency into your system as well as the money you have (use of CDNs, multiple geographical deployment, multiple vendors, etc.) to buy resiliency. Also, you don't want to spend more effort/money on fixing a potential issue which will cost you less to let happen (keep in mind user's discontent as well as raw costs). - Nicolas On Sunday, June 16, 2013 12:59:27 PM UTC+2, Daniel Yogel wrote: > > In the article about node's domains <http://nodejs.org/api/domain.html>, > they say I should not ignore errors - > > *"The better approach is send an error response to the request that >> triggered the error, while letting the others finish in their normal time, >> and stop listening for new requests in that worker."* > > So my question is, on what types of errors should I close the process: > > - Should I close the process on *any* error? > - what If the error *is not part of the req/res cycle* - should I > still close the process? let's say I was doing some calculations on data > from the DB, and then when saving it again to the DB, I got an error as > the > first callback argument - should I close the process ? > - Should I close the process only when I get *"uncaught exception"* ? > What If I use "domains", what's the equivalence there to *"uncaught > exception" *? should in this case every bit of code I write needs to > be inside some domain ? > > *So in general - I would be happy for some general guidelines about when > to close a node.js process.* > > Thanks. > -- -- 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.
