Unhandled errors treatment in firebase-node

[Kirill Slatin]

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.

[Ryan Graham]

I'm grasping at straws here..

It is possible the intention was to make the exception uncatchable, suggesting the authors felt it is inappropriate to attempt to recover from the problem.

~Ryan

--
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 nodejs+un...@googlegroups.com.
To post to this group, send email to nod...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nodejs/aa264ab4-abda-4031-b7ec-92b2c34d80ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Forrest Norvell]

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

​

--