How to handle the nodejs EMFILE exception without modifying ulimit? - asynchronous

Question

I'm new to Node.JS and am stuck with an EMFILE error. I'm after a way of catching the EMFILE exception, and handling it in code.
There seems to be many questions about the "Error: EMFILE, Too many open files" error, but most answers seem to be along the lines of "Increase your ulimit".
My first question is, how do I catch this exception? When I run the below code with many connections, it raises the EMFILE error:
stream = net.createConnection(port, host);
stream.addListener('connect', function() {
return stream.write(request);
});
stream.addListener('data', function(data) {
return console.log(data);
});
stream.addListener('end', function() {
stream.end();
return callback();
});
stream.addListener('timeout', function() {
stream.destroy();
console.log("timeout");
return callback();
});
stream.addListener('error', function(e) {
console.log("this never gets called");
return
});
The exception isn't being caught in the 'error' listener. I've tried to wrap the above in a try{} catch (e) {} and nothing happens. I've used a callback method for createConnection, and it doesn't return any errors.
The only way I have been able to catch the exception is with:
process.on('uncaughtException', function(err) {
console.log(err);
});
which seems unsafe given it's catching everything.
And so my second question is: What is the "best practices" way to catch the error and retry the call?
I've looked at:
https://github.com/isaacs/npm/blob/master/lib/utils/graceful-fs.js
and
Simple nodejs http proxy fails with "too many open files"
as references, but I'm not sure how to apply the graceful method from npm to the createConnection call.
Thanks muchly!

Answer 1

Even if you could catch this exception, is there anything useful you would do about it? If you have a leak somewhere, you need to fix the leak, and if you have normal but very high load, then you'll need to handle this somehow. Either way, when you hit this condition, things are pretty bad in your node process.
Unfortunately, when you handle an uncaughtException event, the only safe thing to do is log an error message and then exit the process. The stack on which the exception was thrown is now gone, and deep internal confusion will likely soon result.
The best solution is to increase the number of file descriptors available to the process. The good news is that file descriptors are really cheap.