Missing the Point of Promises

Oh, yes, of-course, now it makes it perfectly clear!

Reading HN sometimes make me wonder how I'm still getting paid for writing code / managing others that do so. Was software reinvented in the past few years while I was sleeping? Is functional programming taking over the world? Is understanding things like Monads and Promises now a must have for anyone calling themselves a programmer / developer / software engineer / hacker?

Not exactly, unless the fulfilledHandler returns a promise. The examples didn't seem to have that requirement.

If fulfilledHandler is a regular function, then then() is just Functor's fmap.

If fulfilledHandler is allowed to be either variant, then you can imagine then() as applying an implicit return when needed, which makes the types a bit less clear

In this vein, it's also worth looking at Microsoft's "Reactive Extensions" (which have a JS implementation, too.) It's a similarly monadic approach to asynchrony, but deals in "observables" which produce zero or more events, compared to promises which produce only one.

(Edit: corrected "one or more" to "zero or more".)

I wrote a blog post on exactly this a few months ago: http://kybernetikos.com/2012/07/10/design-pattern-wrapper-wi...

And the same can be said about Twisted's Deferred.

They're supposed to make things nicer. Syntactic sugar.

Personally, I don't really see them helping in most cases. They have just as much code and generally rearrange it into a form that I find less readable. For his first example, he provides the callback function (which is actually empty, but whatever) but the promise version doesn't show the function. If it did, it'd be just as verbose and hard to read, if not moreso.

Now, that changes a bit with the .then syntax later. With callbacks, you'd end up with a series of nested callbacks, which can get just as ugly as a series of nested if statements. The .then syntax lets you chain it all together in a more visually pleasing way, and I think it's easier to read, too.

In short, the way promises are often done is wrong (and he's saying so) and there's a proper way to do it. Unfortunately, a lot of frameworks are missing that feature, and so they're just screwed up.

This article made it click for me. I had read several others that went over my head.

The point of promises, as explained in this article, is to mirror the error handling semantics of synchronous code with minimal boilerplate.

In code based on callbacks, if an error occurs somewhere, you must either deal with it locally or pass it along the callback chain manually. Promises mimic the try/catch system.

Here's a variation based on the first example in the WhenJS documentation[0]. It demonstrates the basic control flow, we'll see later why it makes error handling easier:

    function loadImage (src) {
        var deferred = when.defer(),
            img = document.createElement('img');
        img.onload = function () { 
            deferred.resolve(img); 
        };
        img.onerror = function () { 
            deferred.reject(new Error('Image not found: ' + src));
        };
        img.src = src;

        // Return only the promise, so that the caller cannot
        // resolve, reject, or otherwise muck with the original deferred.
        return deferred.promise;
    }

    // example usage:
    loadImage('http://google.com/favicon.ico').then(
        function gotIt(img) {
            document.body.appendChild(img);
            return aSecondPromise;
        },
        function doh(err) {
            document.body.appendChild(document.createTextNode(err));
        }
    ).then(function(/*resolved value of the second promise*/){...});

First, lets focus on the `loadImage()` function, which wraps an async image load into a promise object.

It first creates a deferred object wich has two methods and one property:

* `defered.promise` is an objet with a `then` method that takes two optional handlers (success,error), which returns another promise. This allows chaining (more on that later).

* `defered.resolve(result)` resolves the corresponding promise: it takes one parameter and passes it to the success handler.

* `reject(error)` has similar behaviour but for the error handler.

These two methods are mutually exclusive. If you call one, you can't call the other.

As you can see, `loadImage()` defines two event handlers for the img object, that will either resolve or reject the promise. It schedules the async event, then returns the promise object. The `then` method of the latter registers two handlers one of which will kick in when the async call resolves the promise.

--

There's no point in using promises for trivial code like this.

Their usefulness comes from subtleties in the way the `then()` methods propagate the successes and errors when they are chained.

Success and error handlers are optional. If at a given step a success/error should have been triggered but isn't, the value is passed to the next one of the same kind in the then chain.

Let's take the example in this article:

    getTweetsFor("domenic") // promise-returning async function
        .then(function (tweets) {
            var shortUrls = parseTweetsForUrls(tweets);
            var mostRecentShortUrl = shortUrls[0];
            return expandUrlUsingTwitterApi(mostRecentShortUrl); // promise-returning async function
        })
        .then(doHttpRequest) // promise-returning async function
        .then(
            function (responseBody) {
                console.log("Most recent link text:", responseBody);
            },
            function (error) {
                console.error("Error with the twitterverse:", error);
            }
        );

At each step, the promise can be resolved or rejected. If it is resolved, its result is passed to the next success handler. If if is rejected at any step, the following OK steps are skipped, and the error ends up being handled by the error handler defined in the last then clause. It is thus equivalent to this synchronous code:

    try {
        var tweets = getTweetsFor("domenic"); // blocking
        var shortUrls = parseTweetsForUrls(tweets);
        var mostRecentShortUrl = shortUrls[0];
        var responseBody = doHttpRequest(expandUrlUsingTwitterApi(mostRecentShortUrl)); // blocking x 2
        console.log("Most recent link text:", responseBody);
    } catch (error) {
        console.error("Error with the twitterverse: ", error);
    }

Imagine how messy it would be to propagate the errors in standard callback-based code...

--

One last thing about handlers:

    loadImage(src).then/*1*/(successH, errorH).then/*2 */(successH2, errorH2);

loadImage() returns a first promise and its `then1()` method registers the handlers and returns a promise, whose state will depend on the behaviour of the handlers once one of them is triggered. If the handler (either successH or errorH) returns a value, the promise will pass that value to the next success handler. If the handler throws an exception, the value thrown will be passed to the next error handler, and so on.

This brings us the following parallel, FTA:

1. Promise fulfilled, fulfillment handler returns a value: simple functional transformation

2. Promise fulfilled, fulfillment handler throws an exception: getting data, and throwing an exception in response to it

3. Promise rejected, rejection handler returns a value: a catch clause got the error and handled it

4. Promise rejected, rejection handler throws an exception: a catch clause got the error and re-threw it (or a new one)

At last, a handler can return a new promise. In that case, the handler that is called next will depend on whether that promise is resolved or rejected.

--

Sigh... I'm done. I hope I didn't make things more confusing.

--

[0] https://github.com/cujojs/when/wiki/Examples

The general case of a Future/Promise is that you can design a nicer (sometimes) API. Instead of forcing the caller to provide their own callback functions immediately when they call your function, you can return a Future instead and the client can ask for the data on that whenever. e.g.:

    function read_key(key, cb) {
      database.getItem(domain, key, cb);
    }
    ..
    read_key(key, function(err, res) { ... });
    VS.
    function read_key(key) {
      var future = Future();
      database.getItem(domain, key, future.fulfill);
      return future;
    }
    ...
    var reader = read_key(key);
    ...
    reader.when(function(err, res) { .. } );

As others have noted, you can make a generalization into Sequences that eliminates nested-callback-hell. In Node especially there are a lot of asynchronous calls (and especially especially if you are managing outside data) so they come in handy. I like this library: https://github.com/coolaj86/futures Instead of sequence-members having to return promises themselves, though, they can just call the next() function or not. As an example, you might define your program to do this:

    var obj; // shared data
    var seq = Futures.sequence();
    seq.then(function(next) { ...dosetupstuff... next(obj); })
       .then(fetchMetadataFromDB)
       .then(validateFile)
       .then(createFileInDB)
       .then(copyToOtherDB);

And you might go on. Each function relies on the previous function having completed successfully and calling next(), otherwise the sequence is broken. You can more easily create standardized error handling mechanisms as well. Of course if all your functions are synchronous this doesn't really matter, but getting at an external DB might look something like this:

    function fetchMetadataFromDB(next, obj) {
      db.fetch(query, function(result) { // success
        obj.stuff = result.whatever;
        next(obj);
      },
      function(err) { // error
        ..
      });
    }

A lot of libraries follow that pattern. Without a sequence, your code might start looking like this:

    ..setup stuff;
    function fetchMetadata(obj, cb) { .. }
    fetchMetadata(obj, function (metadata) {
        // validate file:
        validate(metadata, function(file) { // success
          // create file:
          db.create(file, function() { // success
            // copy to other db
            otherdb.copy(file, function() { // success
              ...
            }, function(err) { // copy failed
              ...
            });
          }, function(err) { // create failed
            ...
        }, function(err) { // validate failed
          ...
        });
    });

You could used named functions but that means a given named function must know the name of its successive named function, and that can make your program hard to follow and change. With the sequence approach, you have the whole sequential structure laid out at the top and can inspect functions themselves if you want to, and if a new async part enters the flow you can just insert it in the sequence. With a non-sequence named function approach, you have to jump around all the functions to get a sense of the sequence, and if a new async part enters the flow you have to change the function before to call the new function. You could define all your functions inline, which helps keep the order of execution straight and easy to follow, but adding a new async operation means adding a new level of indentation, so it's called nested-callback-hell.

Good promises libraries (like Q and my RSVP.js: https://github.com/tildeio/rsvp.js) absolutely do support this.

Check out https://github.com/domenic/promise-tests/blob/master/lib/tes... for the tests for this behavior, which most promises libraries (but not jQuery) pass.

As wycats says, this indeed supported by good JS promises. I talked a bit more about the situation in my promise-tests documentation:

https://github.com/domenic/promise-tests#returning-a-promise...

Unfortunately Promises/A omits this, so I didn't address it directly, although I did sneak it into the example code with the `return expandUrlUsingTwitterApi(mostRecentShortUrl);` line.

Well, it is, at least in good implementations. One that I know about and use regularly is somewhat dated, but "feature complete" and as Pythonic as it gets: MochiKit and it's Deffereds: http://mochi.github.com/mochikit/doc/html/MochiKit/Async.htm...

I have not dived into async, so it may have the ability to handle the following and I just don't know it. But here are the things I think it's missing:

- Interception of not only errors explicitly passed up to the callback, but also thrown exceptions (see the paragraph containing "we take care of both intentional and unintentional exceptions")

- Per-task error interception, translation, and re-throwing

- Guarantees like "never both fulfilled and rejected" or "the state never transitions once it's fulfilled or rejected" or "only at most one handler is called, at most one time". For example real bugs in popular libraries have stemmed from calling callbacks with both an error and a result, or calling them twice (with different parameters each time). A speaker at HuJS gave an example of this in one of TJ Hollowaychuk's libraries.

Yes, very true! In fact, many of the the Windows Runtime APIs are async. They get projected identically into C# with `Task` as they do into JavaScript with WinJS promises.

On cancellation, this is actually a feature of several promise libraries. When.js has it, as do WinJS promises (so those cancellable Windows Runtime APIs project just as well into JavaScript). We are hoping to add the feature to Q, but we haven't figured out the exact semantics yet, especially with regards to some of the object-capability security requirements Q attempts to address.

Of course, C# 5 has a huge advantage in their `await` and `async` keywords. But fear not! Shallow coroutines with `yield` are coming in ECMAScript 6 (the next version of JavaScript), and you can build very similar support on top of promises:

http://taskjs.org/

> The thing to understand about a promise is that monadic operations apply

If that's necessary to understand, then javascript isn't the problem. Most developers do not understand monadic operations.

Yes and no. You can have stream-like functionality (piping the response of one promise to another), but that's not what promises are all about.

A promise at its core represents a result that will be available in the future. The other thing you have to understand is that an instance of a promise supports monadic operations (i.e. filter, map, flatMap, depending on the implementation of course, but without these monadic operations any implementation is useless).

What does this mean actually? It means that these promises are composable. Piping is only one usecase, however you can compose them in any way you want.

For instance, you can do something like ... execute tasks A, B and C in parallel and from whichever one finishes first, from its result start tasks D1, D2 ... Dn in parallel, drop whichever of the tasks timeouts or throws an exception, then merge the results of the tasks that succeeded and pass it to task E, which will produce a final response.

I think the main point there was that unless you check 'promises' given to you from other APIs and applications you can't rely on them conforming to the spec.

As authors of Promises/A-consuming libraries, we would like to assume ... that something that is "thenable" actually behaves as a Promises/A promise, with all the power that entails.

If you can make this assumption, you can write very extensive libraries that are entirely agnostic to the implementation of the promises they accept! Whether they be from Q, when.js, or even WinJS, you can use the simple composition rules of the Promises/A spec to build on promise behavior...

Unfortunately, libraries like jQuery break this. This necessitates ugly hacks to detect the presence of objects masquerading as promises, and who call themselves in their API documentation promises, but aren't really Promises/A promises. If the consumers of your API start trying to pass you jQuery promises, you have two choices: fail in mysterious and hard-to-decipher ways when your compositional techniques fail, or fail up-front and block them from using your library entirely. This sucks.

No, jQuery's `pipe` (or their `then` in >= 1.8) still does not do error handling. I updated the article a couple days ago to address this directly:

---

This breaks down into four scenarios, depending on the state of the promise. Here we give their synchronous parallels so you can see why it's crucially important to have semantics for all four:

- Fulfilled, fulfillment handler returns a value: simple functional transformation

- Fulfilled, fulfillment handler throws an exception: getting data, and throwing an exception in response to it

- Rejected, rejection handler returns a value: a catch clause got the error and handled it

- Rejected, rejection handler throws an exception: a catch clause got the error and re-threw it (or a new one)

Without these transformations being applied, you lose all the power of the synchronous/asynchronous parallel, and your so-called "promises" become simple callback aggregators. This is the problem with jQuery's current "promises": they only support scenario 1 above, omitting entirely support for scenarios 2–4.

---

So you get chaining, sure; you can flatten your callback trees into callback lists. That's cool, I guess. But they're still missing the point, which is to allow composability not only of always-successful functions, but of functions that sometimes fail as well.