There's no such thing as "best approach". It's a decision a developer has to make, and the decision should be based on a particular reasons, not on other people's opinions about what the best is.
As far as I can see, the most common approach right now is just trying to catch all common errors manually and pass it to callbacks (maybe using flow control library like async). If something unexpected happens, process will just crash and be restarted, but it is expected to happen rarely enough. I had high hopes for the domains api, but it looks like this idea is either failed or has a very niche use, because I don't really remember any projects that use it. Another interesting idea will be to use synchronous api and generators, but it isn't even possible by default in unstable yet. On Saturday, October 26, 2013 10:27:04 AM UTC+4, Benjamin Zuill-Smith wrote: > > Would others agree from what has been discussed in this thread that the > best approach is to use domains and try/catch? I am looking to prevent my > express server from erroring out. It seems like try/catch will allow a > domain to continue running and thus I can still respond to a user request, > but if I miss something then domains would prevent the server process from > shutting down and I only lose the request. Does this sounds about right? > > On Saturday, July 6, 2013 4:17:28 AM UTC-7, Tony Mobily wrote: >> >> Hi, >> >> I have been writing a bit of code with nodejs, and am sort of "going >> back" to brush things up, checking that I am doing things the right way. >> I recently read this: >> >> http://geoff.greer.fm/2012/06/10/nodejs-dealing-with-errors/ >> >> After a bit of research, I got to this article: >> >> http://benno.id.au/blog/2011/08/08/nodejs-exceptions >> >> And to this SO answer: >> >> >> http://stackoverflow.com/questions/7310521/node-js-best-practice-exception-handling >> >> At the moment, I am only ever throwing() if: >> >> 1) I am enclosing _async_ code with try/catch, like this: >> >> // Get the messages from Json, safely >> try { >> if( ! req.body.messages ) >> throw( new Error("req.body.messages not there") ); >> var messages = JSON.parse(req.body.messages); >> } catch(e) { >> var messages = []; >> } >> >> 2) Something reeeeeeeeaaaaaaaalllllllyyyyyyy bad happens in terms of how >> my module was used. For example a class constructor is missing a necessary >> parameter, etc. >> >> In any other case, I am using next( err ). If something really bad >> happens, for example mongodb dies and calls to the db start failing, I >> handle it with an error manager in express: >> >> app.use( function( err, req, res, next){ >> // ... >> }); >> >> But... does this mean that if my application uses a library that has a >> random throw(), my app will effectively die? >> What's the "current" state of affairs? >> >> Looking at existing code, well, I seem to have gotten it right: nodejs >> libraries tend to only throw when things really aren't supposed to happen. >> For example in qs/lib/querystring.js: >> >> function stringifyString(str, prefix) { >> if (!prefix) throw new TypeError('stringify expects an object'); >> return prefix + '=' + encodeURIComponent(str); >> } >> >> But... am I missing something? >> Would this be correct: >> >> * throw() when the program really deserves to die, and not for external >> causes (see: the db server goes down, etc.) >> * Always use next( err ) if anything goes wrong (business as usual) >> * Figure out if some libraries emit events, and listen to them if >> necessary >> >> Bye, >> >> Merc. >> > -- -- 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.
