Iterating Generators Asynchronously

What do generators have to do with async coding patterns, fixing problems with callbacks, and the like? Let’s get to answering that important question.

We should revisit one of our scenarios from Chapter 3. Let’s recall the callback approach:

function foo(x,y,cb) {
    ajax(
        "http://some.url.1/?x=" + x + "&y=" + y,
        cb
    );
}
foo( 11, 31, function(err,text) {
    if (err) {
        console.error( err );
    }
    else {
        console.log( text );
    }
} );

If we wanted to express this same task flow control with a generator, we could do:

function foo(x,y) {
    ajax(
        "http://some.url.1/?x=" + x + "&y=" + y,
        function(err,data){
            if (err) {
                // throw an error into `*main()`
                it.throw( err );
            }
            else {
                // resume `*main()` with received `data`
                it.next( data );
            }
        }
    );
}
function *main() {
    try {
        var text = yield foo( 11, 31 );
        console.log( text );
    }
    catch (err) {
        console.error( err );
    }
}
var it = main();
// start it all up!
it.next();

At first glance, this snippet is longer, and perhaps a little more complex looking, than the callback snippet before it. But don’t let that impression get you off track. The generator snippet is actually much better! But there’s a lot going on for us to explain.

First, let’s look at this part of the code, which is the most important:

var text = yield foo( 11, 31 );
console.log( text );

Think about how that code works for a moment. We’re calling a normal function foo(..) and we’re apparently able to get back the text from the Ajax call, even though it’s asynchronous.

How is that possible? If you recall the beginning of Chapter 1, we had almost identical code:

var data = ajax( "..url 1.." );
console.log( data );

And that code didn’t work! Can you spot the difference? It’s the yield used in a generator.

That’s the magic! That’s what allows us to have what appears to be blocking, synchronous code, but it doesn’t actually block the whole program; it only pauses/blocks the code in the generator itself.

In yield foo(11,31), first the foo(11,31) call is made, which returns nothing (aka undefined), so we’re making a call to request data, but we’re actually then doing yield undefined. That’s OK, because the code is not currently relying on a yielded value to do anything interesting. We’ll revisit this point later in the chapter.

We’re not using yield in a message passing sense here, only in a flow control sense to pause/block. Actually, it will have message passing, but only in one direction, after the generator is resumed.

So, the generator pauses at the yield, essentially asking the question, “what value should I return to assign to the variable text?” Who’s going to answer that question?

Look at foo(..). If the Ajax request is successful, we call:

it.next( data );

That’s resuming the generator with the response data, which means that our paused yield expression receives that value directly, and then as it restarts the generator code, that value gets assigned to the local variable text.

Pretty cool, huh?

Take a step back and consider the implications. We have totally synchronous-looking code inside the generator (other than the yield keyword itself), but hidden behind the scenes, inside of foo(..), the operations can complete asynchronously.

That’s huge! That’s a nearly perfect solution to our previously stated problem with callbacks not being able to express asynchrony in a sequential, synchronous fashion that our brains can relate to.

In essence, we are abstracting the asynchrony away as an implementation detail, so that we can reason synchronously/sequentially about our flow control: “Make an Ajax request, and when it finishes print out the response.” And of course, we just expressed two steps in the flow control, but this same capability extends without bounds, to let us express however many steps we need to.

Tip: This is such an important realization, just go back and read the last three paragraphs again to let it sink in!

Synchronous Error Handling

But the preceding generator code has even more goodness to yield to us. Let’s turn our attention to the try..catch inside the generator:

try {
    var text = yield foo( 11, 31 );
    console.log( text );
}
catch (err) {
    console.error( err );
}

How does this work? The foo(..) call is asynchronously completing, and doesn’t try..catch fail to catch asynchronous errors, as we looked at in Chapter 3?

We already saw how the yield lets the assignment statement pause to wait for foo(..) to finish, so that the completed response can be assigned to text. The awesome part is that this yield pausing also allows the generator to catch an error. We throw that error into the generator with this part of the earlier code listing:

if (err) {
    // throw an error into `*main()`
    it.throw( err );
}

The yield-pause nature of generators means that not only do we get synchronous-looking return values from async function calls, but we can also synchronously catch errors from those async function calls!

So we’ve seen we can throw errors into a generator, but what about throwing errors out of a generator? Exactly as you’d expect:

function *main() {
    var x = yield "Hello World";
    yield x.toLowerCase();    // cause an exception!
}
var it = main();
it.next().value;            // Hello World
try {
    it.next( 42 );
}
catch (err) {
    console.error( err );    // TypeError
}

Of course, we could have manually thrown an error with throw .. instead of causing an exception.

We can even catch the same error that we throw(..) into the generator, essentially giving the generator a chance to handle it but if it doesn’t, the iterator code must handle it:

function *main() {
    var x = yield "Hello World";
    // never gets here
    console.log( x );
}
var it = main();
it.next();
try {
    // will `*main()` handle this error? we'll see!
    it.throw( "Oops" );
}
catch (err) {
    // nope, didn't handle it!
    console.error( err );            // Oops
}

Synchronous-looking error handling (via try..catch) with async code is a huge win for readability and reason-ability.