up vote 2 down vote favorite

I'm currently working on a node.js app and I'm having the ususal asynchronous code issue.

For learning purposes I'm implementing an http server over node's tcp module.

This server supports (express like) routes. For example I have code that looks like this:

server.any("/someRoute",function(req,resp){
    resp.end("this text is sent to clients via http")
});

The server needs to be able to withstand failure, I do not want to crash the whole server when there is a problem in a function passed to any. The problem occurs when I'm writing code that looks like:

server.any("/someRoute",function(req,resp){
    setTimeout(function(){
        throw "This won't get catched";
    },100);
});

I don't see how I possible can catch the error here. I don't want to crash the server over one server-side glitch, instead I want to serve 500.

The only solutions I've been able to come up with are really not expressive. I've only come up with using process.on("uncaughtException",callback) and similar code using node 0.8 Domains (which is a partial remedy but Domains are currently buggy and this is still not very expressive since I end up having to create a domain for every handle).

What I would like to accomplish is binding throw actions from a function to a scope, the ideal solution is something like binding all thrown errors from a function to a specific handler function.

Is this possible? What is the best practice to handle errors in this case?

I'd like to emphasise that it should be able to continue serving requests after a bad requests, and restarting the server on every request or creating domains for every handler and catching their uncaught exceptions seems like a bad idea to me.

share|improve this question
100% accept rate
AFAIK, catching thrown exceptions from async code is impossible outside of something like domains (which sounds exaclty like "binding all thrown errors from a function to a specific handler function"); the alternative is to use the standard Node.js callback style where the first parameter is an error instead of throwing (and is in fact why this pattern is so prevalent). – Brandon Tilley 2 days ago
I have to be able to work with code I did not write on my own. The dream solution would be something like functionName.exceptionHandler = someFunction(exception) or something of the sort. – Benjamin Gruenbaum 2 days ago
Totally understand--but I'm not sure you'll get that very easily. You have to intercept the calls (which is what Domains attempts to do for built-in event emitters). (Perhaps some theoretical extension of JavaScript--think CoffeeScript--could do the necessary code generation for you.) The fact of the matter is, throwing from asynchronous code is bad form, and for instance where it can't be helped (perhaps a JSON.parse fails, etc.), the uncaughtException event is your ticket to saving your app (although it would surely be better for the library to catch inside its own code). – Brandon Tilley 2 days ago
@BrandonTilley I would appreciate your feedback on my own answer – Benjamin Gruenbaum 2 days ago
feedback

1 Answer

up vote 1 down vote

I ended up using domains, I have created the following file I called mistake.js which contains the following code:

var domain=require("domain");
module.exports = function(func){
    var F = function(){};
    var dom = domain.create();
    F.prototype.catch = function(errHandle){
        var args = arguments;
        dom.on("error",function(err){
            return errHandle(err);
        }).run(function(){
            func.call(null,args);
        });
        return this;
    }
    return new F();
};

Here is some example usage:

var atry = require("./mistake.js");

atry(function() {
    setTimeout(function(){
        throw "something";
    },1000);
}).catch(function(err){
    console.log("caught "+err);
});

It also works like normal catch for synchronous code

atry(function() {
    throw "something";
}).catch(function(err){
    console.log("caught "+err);
});

I would appreciate some feedback on the solution

share|improve this answer
I think that's quite nice--keeps all the domain creation in its own place. – Brandon Tilley 2 days ago
feedback

Your Answer

 
or
required, but never shown
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.