The pass pattern

Javascript is a programming language that has most of the killer functional programming features you can possibly bake into a C syntax styled language with a hint of prototypical inheritance from the self programming language. This presents you with an interesting multi-paradigm programming environment that through better or worse practices can let you choose which style to program in.

When i write javascript my inner geek gets all giddy because it’s always the perfect excuse for me to exercise functional programming practices in a widely accepted mainstream language. I love functional programming so much in javascript that the library i get the most mileage out of by a landslide is underscore.js, a functional programming library for javascript. Even if you exclude the fact that i use underscore.js in both client side javascript and server side in node.js, it still remains the library that i use the most independently in each environment.

Patterns and abstraction

In functional programming whenever you find yourself typing a similar code pattern multiple times you should consider abstracting it. This is actually true with most programming languages but something of a religious practice in functional programming. However, functional programming languages like javascript have the advantage of having high order functions and lexical closures allowing you to abstract certain patterns better and more concisely then is possible in non functional languages.

Error handling in node.js

As an awesomely consistent and well implemented set of APIs, all API calls in node.js that perform any kind of IO take a function callback to run on IO completion. This is a very fundamental practice at the core of the node.js asynchronous evented model. A familiar site to anyone familiar with node is the pattern of arguments that are passed to the callback. Typically, asynchronous callbacks will take one or two arguments, (error) and (error, value) . The most important part for this article being that error is always the first argument passed to the callback.

The error passed as the first argument to any aysnchronous callback is representative of any errors that might have occurred during the asynchronous operation. Error will be false if no error was raised and non false otherwise. In node.js you often have nested aysnchronous requests and a common approach to error handling is to pass the errors back up the event chain to be handled by a layer knowing what to do with it. This is demonstrated in the bellow pseudo code js example.

var express = require("express"),
    redis   = require("redis").createClient(),
    app     = express.createServer();

functon getLatestNews(next) {
    redis.lrange("news", 0, 25, function(error, value) {
        if (error) {
            next("failed fetching news");
        } else {
            next(false, value);
        }
    });
}

app.get("/", function(req, res){
    getLatestNews(function(error, news) {
        if (error) {
            globalErrorHandler(error);
        } else {
            res.send(news);
        }
    });
});

app.listen(80);

There it is the error passing pattern. If you write node.js code you can probably find this pattern throughout your code base. If you can’t it means you’re probably not handling errors which is a big no go.

The pattern can be written a couple different ways

/**
 * strictly nested approach
 */
if (error) {
    // pass failure
    next(error);
} else {
    // pass success
    next(false);
}

/**
 * refactored to avoid deeply nested code
 */
if (error) {
    // pass failure and return
    next(error);
    return;
}

// do work
// pass success
next(false);

So the money making question is how do we factor out this repetitive pattern being the ace functional programmers that we like to think that we are?

Heres the solution i came up with, i call it the pass pattern. I call it the pass pattern, but really it’s more of an abstraction.

var express = require("express"),
    redis   = require("redis").createClient(),
    app     = express.createServer();

function pass(next, after) {
    return function(error, value) {
        if (error) {
            after(error, value);
        } else {
            next(value);
        }
    };
}

functon getLatestNews(next) {
    redis.lrange("news", 0, 25, pass(function(value) {
        next(false, value);
    }, next));
}

app.get("/", function(req, res){
    getLatestNews(pass(function(news) {
        res.send(news);
    }, globalErrorHandler));
});

app.listen(80);

So this requires you to setup a function called pass which acts as a closure generator for augmenting the asynchronous callback. The error checking gets dropped from the asynchronous callback, yet the error checking still takes place. The asynchronous callback itself is only ran when no error is present and as a byproduct, we can safely drop the error argument from the first argument of the callback. Just as important, the next callback is automatically forwarded or “passed” the error if one is present.

The above example of pass is just introductory code. The full version of the pass abstraction i use in my code is as follows.

// Yeah i use underscore.js so much i add it as a mixin to underscore
_.mixin({
    pass: function(next, after, customError, context) {
        return function(error) {
            var args = Array.prototype.slice.call(arguments, 1);
            if (error) {
                args.unshift(customError || error);
                after.apply(context, args);
            } else {
                next.apply(context, args);
            }
        }
    }
});

This version allows me to override error messages so if i get back a DB failure error from the database while calling it from the registration form i can override the message with something more meaningful to the user that will get passed along instead. My version also allows context binding so i can avoid some var self = this; annoyances.

Theta Waves

Break it, Fix it, Repeat.

Patterns and abstraction

Error handling in node.js

Recomended Reading

Comments