You typically see code like this in streaming parsers, where you want to do all of the processing for a chunk of data before emitting any errors so as not to lose your place in the stream (node-redis does something very similar). I also believe (although I’m not entirely sure) that most of the Firebase API is meant to be used in both the browser and on the server, so the code in question is probably making few assumptions about how the errors are going to be handled (or whether there’s a mechanism like process.nextTick or Node’s (soon-to-be deprecated) domains available). It’s not the most pleasant pattern to encounter as an API user, but generic JavaScript is pretty poor at supporting async error handling, so that’s what you get.
F On Sat, Jan 10, 2015 at 5:09 AM, Kirill Slatin <[email protected]> wrote: > Humbly asking someone to explain to me what the authors of node.js wrapper > for Firebase API meant with the following code. > The code is extracted from the official downloadable bundle for node.js > (file firebase-node.js). > function fc(a) { > try { > a() > } catch (b) { > *setTimeout*(function () { > throw b; > }, 0) > } > }; > > Unfortunately the file is minimized and you can not tell much from > function and variable names, but debugger shows that this is an interceptor > of errors which happen in callbacks specified for FB events. > The code in question is the *setTimeout* in catch block. > The implication of such an asynchronous code is that once FB got a bunch > of events simultaneously (assume 'child_added' event on application start > which actually reports branch contents on a given key), it first consumes > them all, reaches a place where an exception is thrown as many times as > event has occurred, and then starts spitting exceptions as a machine-gun. > Given you catch these unhandled exceptions with a > *process.on('unhandledException')* handler for example, and do a proper > .exit(1), you will have the only exception *reported* but multiple > exceptions *happened*, including all output operations that preceded > those exceptions in firebase event handlers. > > So far I couldn't conclude any benefit if this extra setTimeout in the > catch block. > > -- > Job board: http://jobs.nodejs.org/ > New group rules: > https://gist.github.com/othiym23/9886289#file-moderation-policy-md > Old group rules: > 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 unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/nodejs/aa264ab4-abda-4031-b7ec-92b2c34d80ed%40googlegroups.com > <https://groups.google.com/d/msgid/nodejs/aa264ab4-abda-4031-b7ec-92b2c34d80ed%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Job board: http://jobs.nodejs.org/ New group rules: https://gist.github.com/othiym23/9886289#file-moderation-policy-md Old group rules: 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/CAHG3qKoTSxJ7HKMJDNqjQE-4ZvCfD4ooU-U7g0wqa0Rx0pkFSw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
