FWIW, another common gotcha WRT domains (that trycatch addresses) is that
since domains don't "catch" errors, code after a domain.run does not run
when a run throws. E.g.,
var d = require('domain').create();
d.on('error', function(err){
console.log('here');
});
d.run(function(){
throw new Error('example');
});
console.log('this does not happen')
vs...
trycatch(function() {
throw new Error('example');
}, function(err) {
console.log('here');
})
console.log('this happens')
The reason this is important is due to a concept known as stack tearing.
Essentially, you don't know what code is *meant* to / would happen after
the error, so resuming on error means you will be in an undefined state.
try/catch solves this, but domains don't use try/catch, they use a special
form of process.on('uncaughtException'). I'll address all this further in
my post, but as I was reviewing your very good references (specifically
http://stackoverflow.com/questions/7310521/node-js-best-practice-exception-handling)
it came to mind since there's more happening than meets the eye.
Cheers,
Adam Crabtree
On Mon, Jul 8, 2013 at 10:38 AM, Adam Crabtree <atcrabt...@gmail.com> wrote:
> The short answer is to use domains to help you die gracefully, but an
> uncaughtException or a domain error REQUIRES a restart of the process.
>
> The long answer is use trycatch, https://github.com/crabdude/trycatch.
> Because domains are not the equivalent of node.js' "On Error Resume Next"
> (See
> http://nodejs.org/docs/latest/api/all.html#all_warning_don_t_ignore_errors),
> there are certain obvious failure cases that resuming on error will place
> your code into a bad state (e.g., EventEmitter handler errors:
> https://github.com/joyent/node/issues/5114). trycatch resolves these by
> shimming EventEmitter and wrapping all handlers in try/catch, moving much
> closer to "On Error Resume Next". It also doesn't catch errors that have
> torn multiple layers of core stack (or to put it another way, only catches
> core errors that are TypeErrors occurring at the first layer of core logic).
>
> I'm currently wrapping up a comprehensive blog post on node.js error
> handling. I'll followup here with a link when it's posted.
>
> Cheers,
> Adam Crabtree
>
>
> On Mon, Jul 8, 2013 at 9:17 AM, Martin Cooper <mfncoo...@gmail.com> wrote:
>
>>
>>
>>
>> On Sun, Jul 7, 2013 at 10:01 PM, joel <orengo...@gmail.com> wrote:
>>
>>> I started working a project <https://github.com/oren/domains-examples>that
>>> demonstrate domains both on vanilla node and with express (it's based
>>> on the nodeconf session).
>>> take a look and feel free to send pull requests.
>>>
>>> from some reason the /database route does not get caught by the domain
>>> -
>>> https://github.com/oren/domains-examples/blob/master/express/server.js#L35
>>> any idea what's missing there?
>>
>>
>> The problem is with Express. It wraps a try / catch around your request
>> handler function, such that any synchronous exception (e.g. from your
>> '/throw' handler) will be caught by that, and not handled by the domain.
>> The reason your '/database' handler works is that the exception is thrown
>> outside of the request handler itself, because of that setTimeout() call.
>>
>> --
>> Martin Cooper
>>
>>
>> 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/<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<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<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 reeeeeeeeaaaaaaaalllllllyyyyyy**y 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 nodejs@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> nodejs+unsubscr...@googlegroups.com
>>> 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 nodejs+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>>
>> --
>> --
>> 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 nodejs@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com
>> 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 nodejs+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> Better a little with righteousness
> than much gain with injustice.
> Proverbs 16:8
>
--
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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
