A promise library for JavaScript

Related tags

Control Flow q
Overview

Build Status CDNJS

Q logo

If a function cannot return a value or throw an exception without blocking, it can return a promise instead. A promise is an object that represents the return value or the thrown exception that the function may eventually provide. A promise can also be used as a proxy for a remote object to overcome latency.

On the first pass, promises can mitigate the “Pyramid of Doom”: the situation where code marches to the right faster than it marches forward.

step1(function (value1) {
    step2(value1, function(value2) {
        step3(value2, function(value3) {
            step4(value3, function(value4) {
                // Do something with value4
            });
        });
    });
});

With a promise library, you can flatten the pyramid.

Q.fcall(promisedStep1)
.then(promisedStep2)
.then(promisedStep3)
.then(promisedStep4)
.then(function (value4) {
    // Do something with value4
})
.catch(function (error) {
    // Handle any error from all above steps
})
.done();

With this approach, you also get implicit error propagation, just like try, catch, and finally. An error in promisedStep1 will flow all the way to the catch function, where it’s caught and handled. (Here promisedStepN is a version of stepN that returns a promise.)

The callback approach is called an “inversion of control”. A function that accepts a callback instead of a return value is saying, “Don’t call me, I’ll call you.”. Promises un-invert the inversion, cleanly separating the input arguments from control flow arguments. This simplifies the use and creation of API’s, particularly variadic, rest and spread arguments.

Getting Started

The Q module can be loaded as:

  • A <script> tag (creating a Q global variable): ~2.5 KB minified and gzipped.
  • A Node.js and CommonJS module, available in npm as the q package
  • An AMD module
  • A component as microjs/q
  • Using bower as q#^1.4.1
  • Using NuGet as Q

Q can exchange promises with jQuery, Dojo, When.js, WinJS, and more.

Resources

Our wiki contains a number of useful resources, including:

  • A method-by-method Q API reference.
  • A growing examples gallery, showing how Q can be used to make everything better. From XHR to database access to accessing the Flickr API, Q is there for you.
  • There are many libraries that produce and consume Q promises for everything from file system/database access or RPC to templating. For a list of some of the more popular ones, see Libraries.
  • If you want materials that introduce the promise concept generally, and the below tutorial isn't doing it for you, check out our collection of presentations, blog posts, and podcasts.
  • A guide for those coming from jQuery's $.Deferred.

We'd also love to have you join the Q-Continuum mailing list.

Tutorial

Promises have a then method, which you can use to get the eventual return value (fulfillment) or thrown exception (rejection).

promiseMeSomething()
.then(function (value) {
}, function (reason) {
});

If promiseMeSomething returns a promise that gets fulfilled later with a return value, the first function (the fulfillment handler) will be called with the value. However, if the promiseMeSomething function gets rejected later by a thrown exception, the second function (the rejection handler) will be called with the exception.

Note that resolution of a promise is always asynchronous: that is, the fulfillment or rejection handler will always be called in the next turn of the event loop (i.e. process.nextTick in Node). This gives you a nice guarantee when mentally tracing the flow of your code, namely that then will always return before either handler is executed.

In this tutorial, we begin with how to consume and work with promises. We'll talk about how to create them, and thus create functions like promiseMeSomething that return promises, below.

Propagation

The then method returns a promise, which in this example, I’m assigning to outputPromise.

var outputPromise = getInputPromise()
.then(function (input) {
}, function (reason) {
});

The outputPromise variable becomes a new promise for the return value of either handler. Since a function can only either return a value or throw an exception, only one handler will ever be called and it will be responsible for resolving outputPromise.

  • If you return a value in a handler, outputPromise will get fulfilled.

  • If you throw an exception in a handler, outputPromise will get rejected.

  • If you return a promise in a handler, outputPromise will “become” that promise. Being able to become a new promise is useful for managing delays, combining results, or recovering from errors.

If the getInputPromise() promise gets rejected and you omit the rejection handler, the error will go to outputPromise:

var outputPromise = getInputPromise()
.then(function (value) {
});

If the input promise gets fulfilled and you omit the fulfillment handler, the value will go to outputPromise:

var outputPromise = getInputPromise()
.then(null, function (error) {
});

Q promises provide a fail shorthand for then when you are only interested in handling the error:

var outputPromise = getInputPromise()
.fail(function (error) {
});

If you are writing JavaScript for modern engines only or using CoffeeScript, you may use catch instead of fail.

Promises also have a fin function that is like a finally clause. The final handler gets called, with no arguments, when the promise returned by getInputPromise() either returns a value or throws an error. The value returned or error thrown by getInputPromise() passes directly to outputPromise unless the final handler fails, and may be delayed if the final handler returns a promise.

var outputPromise = getInputPromise()
.fin(function () {
    // close files, database connections, stop servers, conclude tests
});
  • If the handler returns a value, the value is ignored
  • If the handler throws an error, the error passes to outputPromise
  • If the handler returns a promise, outputPromise gets postponed. The eventual value or error has the same effect as an immediate return value or thrown error: a value would be ignored, an error would be forwarded.

If you are writing JavaScript for modern engines only or using CoffeeScript, you may use finally instead of fin.

Chaining

There are two ways to chain promises. You can chain promises either inside or outside handlers. The next two examples are equivalent.

return getUsername()
.then(function (username) {
    return getUser(username)
    .then(function (user) {
        // if we get here without an error,
        // the value returned here
        // or the exception thrown here
        // resolves the promise returned
        // by the first line
    })
});
return getUsername()
.then(function (username) {
    return getUser(username);
})
.then(function (user) {
    // if we get here without an error,
    // the value returned here
    // or the exception thrown here
    // resolves the promise returned
    // by the first line
});

The only difference is nesting. It’s useful to nest handlers if you need to capture multiple input values in your closure.

function authenticate() {
    return getUsername()
    .then(function (username) {
        return getUser(username);
    })
    // chained because we will not need the user name in the next event
    .then(function (user) {
        return getPassword()
        // nested because we need both user and password next
        .then(function (password) {
            if (user.passwordHash !== hash(password)) {
                throw new Error("Can't authenticate");
            }
        });
    });
}

Combination

You can turn an array of promises into a promise for the whole, fulfilled array using all.

return Q.all([
    eventualAdd(2, 2),
    eventualAdd(10, 20)
]);

If you have a promise for an array, you can use spread as a replacement for then. The spread function “spreads” the values over the arguments of the fulfillment handler. The rejection handler will get called at the first sign of failure. That is, whichever of the received promises fails first gets handled by the rejection handler.

function eventualAdd(a, b) {
    return Q.spread([a, b], function (a, b) {
        return a + b;
    })
}

But spread calls all initially, so you can skip it in chains.

return getUsername()
.then(function (username) {
    return [username, getUser(username)];
})
.spread(function (username, user) {
});

The all function returns a promise for an array of values. When this promise is fulfilled, the array contains the fulfillment values of the original promises, in the same order as those promises. If one of the given promises is rejected, the returned promise is immediately rejected, not waiting for the rest of the batch. If you want to wait for all of the promises to either be fulfilled or rejected, you can use allSettled.

Q.allSettled(promises)
.then(function (results) {
    results.forEach(function (result) {
        if (result.state === "fulfilled") {
            var value = result.value;
        } else {
            var reason = result.reason;
        }
    });
});

The any function accepts an array of promises and returns a promise that is fulfilled by the first given promise to be fulfilled, or rejected if all of the given promises are rejected.

Q.any(promises)
.then(function (first) {
    // Any of the promises was fulfilled.
}, function (error) {
    // All of the promises were rejected.
});

Sequences

If you have a number of promise-producing functions that need to be run sequentially, you can of course do so manually:

return foo(initialVal).then(bar).then(baz).then(qux);

However, if you want to run a dynamically constructed sequence of functions, you'll want something like this:

var funcs = [foo, bar, baz, qux];

var result = Q(initialVal);
funcs.forEach(function (f) {
    result = result.then(f);
});
return result;

You can make this slightly more compact using reduce:

return funcs.reduce(function (soFar, f) {
    return soFar.then(f);
}, Q(initialVal));

Or, you could use the ultra-compact version:

return funcs.reduce(Q.when, Q(initialVal));

Handling Errors

One sometimes-unintuitive aspect of promises is that if you throw an exception in the fulfillment handler, it will not be caught by the error handler.

return foo()
.then(function (value) {
    throw new Error("Can't bar.");
}, function (error) {
    // We only get here if "foo" fails
});

To see why this is, consider the parallel between promises and try/catch. We are try-ing to execute foo(): the error handler represents a catch for foo(), while the fulfillment handler represents code that happens after the try/catch block. That code then needs its own try/catch block.

In terms of promises, this means chaining your rejection handler:

return foo()
.then(function (value) {
    throw new Error("Can't bar.");
})
.fail(function (error) {
    // We get here with either foo's error or bar's error
});

Progress Notification

It's possible for promises to report their progress, e.g. for tasks that take a long time like a file upload. Not all promises will implement progress notifications, but for those that do, you can consume the progress values using a third parameter to then:

return uploadFile()
.then(function () {
    // Success uploading the file
}, function (err) {
    // There was an error, and we get the reason for error
}, function (progress) {
    // We get notified of the upload's progress as it is executed
});

Like fail, Q also provides a shorthand for progress callbacks called progress:

return uploadFile().progress(function (progress) {
    // We get notified of the upload's progress
});

The End

When you get to the end of a chain of promises, you should either return the last promise or end the chain. Since handlers catch errors, it’s an unfortunate pattern that the exceptions can go unobserved.

So, either return it,

return foo()
.then(function () {
    return "bar";
});

Or, end it.

foo()
.then(function () {
    return "bar";
})
.done();

Ending a promise chain makes sure that, if an error doesn’t get handled before the end, it will get rethrown and reported.

This is a stopgap. We are exploring ways to make unhandled errors visible without any explicit handling.

The Beginning

Everything above assumes you get a promise from somewhere else. This is the common case. Every once in a while, you will need to create a promise from scratch.

Using Q.fcall

You can create a promise from a value using Q.fcall. This returns a promise for 10.

return Q.fcall(function () {
    return 10;
});

You can also use fcall to get a promise for an exception.

return Q.fcall(function () {
    throw new Error("Can't do it");
});

As the name implies, fcall can call functions, or even promised functions. This uses the eventualAdd function above to add two numbers.

return Q.fcall(eventualAdd, 2, 2);

Using Deferreds

If you have to interface with asynchronous functions that are callback-based instead of promise-based, Q provides a few shortcuts (like Q.nfcall and friends). But much of the time, the solution will be to use deferreds.

var deferred = Q.defer();
FS.readFile("foo.txt", "utf-8", function (error, text) {
    if (error) {
        deferred.reject(new Error(error));
    } else {
        deferred.resolve(text);
    }
});
return deferred.promise;

Note that a deferred can be resolved with a value or a promise. The reject function is a shorthand for resolving with a rejected promise.

// this:
deferred.reject(new Error("Can't do it"));

// is shorthand for:
var rejection = Q.fcall(function () {
    throw new Error("Can't do it");
});
deferred.resolve(rejection);

This is a simplified implementation of Q.delay.

function delay(ms) {
    var deferred = Q.defer();
    setTimeout(deferred.resolve, ms);
    return deferred.promise;
}

This is a simplified implementation of Q.timeout

function timeout(promise, ms) {
    var deferred = Q.defer();
    Q.when(promise, deferred.resolve);
    delay(ms).then(function () {
        deferred.reject(new Error("Timed out"));
    });
    return deferred.promise;
}

Finally, you can send a progress notification to the promise with deferred.notify.

For illustration, this is a wrapper for XML HTTP requests in the browser. Note that a more thorough implementation would be in order in practice.

function requestOkText(url) {
    var request = new XMLHttpRequest();
    var deferred = Q.defer();

    request.open("GET", url, true);
    request.onload = onload;
    request.onerror = onerror;
    request.onprogress = onprogress;
    request.send();

    function onload() {
        if (request.status === 200) {
            deferred.resolve(request.responseText);
        } else {
            deferred.reject(new Error("Status code was " + request.status));
        }
    }

    function onerror() {
        deferred.reject(new Error("Can't XHR " + JSON.stringify(url)));
    }

    function onprogress(event) {
        deferred.notify(event.loaded / event.total);
    }

    return deferred.promise;
}

Below is an example of how to use this requestOkText function:

requestOkText("http://localhost:3000")
.then(function (responseText) {
    // If the HTTP response returns 200 OK, log the response text.
    console.log(responseText);
}, function (error) {
    // If there's an error or a non-200 status code, log the error.
    console.error(error);
}, function (progress) {
    // Log the progress as it comes in.
    console.log("Request progress: " + Math.round(progress * 100) + "%");
});

Using Q.Promise

This is an alternative promise-creation API that has the same power as the deferred concept, but without introducing another conceptual entity.

Rewriting the requestOkText example above using Q.Promise:

function requestOkText(url) {
    return Q.Promise(function(resolve, reject, notify) {
        var request = new XMLHttpRequest();

        request.open("GET", url, true);
        request.onload = onload;
        request.onerror = onerror;
        request.onprogress = onprogress;
        request.send();

        function onload() {
            if (request.status === 200) {
                resolve(request.responseText);
            } else {
                reject(new Error("Status code was " + request.status));
            }
        }

        function onerror() {
            reject(new Error("Can't XHR " + JSON.stringify(url)));
        }

        function onprogress(event) {
            notify(event.loaded / event.total);
        }
    });
}

If requestOkText were to throw an exception, the returned promise would be rejected with that thrown exception as the rejection reason.

The Middle

If you are using a function that may return a promise, but just might return a value if it doesn’t need to defer, you can use the “static” methods of the Q library.

The when function is the static equivalent for then.

return Q.when(valueOrPromise, function (value) {
}, function (error) {
});

All of the other methods on a promise have static analogs with the same name.

The following are equivalent:

return Q.all([a, b]);
return Q.fcall(function () {
    return [a, b];
})
.all();

When working with promises provided by other libraries, you should convert it to a Q promise. Not all promise libraries make the same guarantees as Q and certainly don’t provide all of the same methods. Most libraries only provide a partially functional then method. This thankfully is all we need to turn them into vibrant Q promises.

return Q($.ajax(...))
.then(function () {
});

If there is any chance that the promise you receive is not a Q promise as provided by your library, you should wrap it using a Q function. You can even use Q.invoke as a shorthand.

return Q.invoke($, 'ajax', ...)
.then(function () {
});

Over the Wire

A promise can serve as a proxy for another object, even a remote object. There are methods that allow you to optimistically manipulate properties or call functions. All of these interactions return promises, so they can be chained.

direct manipulation         using a promise as a proxy
--------------------------  -------------------------------
value.foo                   promise.get("foo")
value.foo = value           promise.put("foo", value)
delete value.foo            promise.del("foo")
value.foo(...args)          promise.post("foo", [args])
value.foo(...args)          promise.invoke("foo", ...args)
value(...args)              promise.fapply([args])
value(...args)              promise.fcall(...args)

If the promise is a proxy for a remote object, you can shave round-trips by using these functions instead of then. To take advantage of promises for remote objects, check out Q-Connection.

Even in the case of non-remote objects, these methods can be used as shorthand for particularly-simple fulfillment handlers. For example, you can replace

return Q.fcall(function () {
    return [{ foo: "bar" }, { foo: "baz" }];
})
.then(function (value) {
    return value[0].foo;
});

with

return Q.fcall(function () {
    return [{ foo: "bar" }, { foo: "baz" }];
})
.get(0)
.get("foo");

Adapting Node

If you're working with functions that make use of the Node.js callback pattern, where callbacks are in the form of function(err, result), Q provides a few useful utility functions for converting between them. The most straightforward are probably Q.nfcall and Q.nfapply ("Node function call/apply") for calling Node.js-style functions and getting back a promise:

return Q.nfcall(FS.readFile, "foo.txt", "utf-8");
return Q.nfapply(FS.readFile, ["foo.txt", "utf-8"]);

If you are working with methods, instead of simple functions, you can easily run in to the usual problems where passing a method to another function—like Q.nfcall—"un-binds" the method from its owner. To avoid this, you can either use Function.prototype.bind or some nice shortcut methods we provide:

return Q.ninvoke(redisClient, "get", "user:1:id");
return Q.npost(redisClient, "get", ["user:1:id"]);

You can also create reusable wrappers with Q.denodeify or Q.nbind:

var readFile = Q.denodeify(FS.readFile);
return readFile("foo.txt", "utf-8");

var redisClientGet = Q.nbind(redisClient.get, redisClient);
return redisClientGet("user:1:id");

Finally, if you're working with raw deferred objects, there is a makeNodeResolver method on deferreds that can be handy:

var deferred = Q.defer();
FS.readFile("foo.txt", "utf-8", deferred.makeNodeResolver());
return deferred.promise;

Long Stack Traces

Q comes with optional support for “long stack traces,” wherein the stack property of Error rejection reasons is rewritten to be traced along asynchronous jumps instead of stopping at the most recent one. As an example:

function theDepthsOfMyProgram() {
  Q.delay(100).done(function explode() {
    throw new Error("boo!");
  });
}

theDepthsOfMyProgram();

usually would give a rather unhelpful stack trace looking something like

Error: boo!
    at explode (/path/to/test.js:3:11)
    at _fulfilled (/path/to/test.js:q:54)
    at resolvedValue.promiseDispatch.done (/path/to/q.js:823:30)
    at makePromise.promise.promiseDispatch (/path/to/q.js:496:13)
    at pending (/path/to/q.js:397:39)
    at process.startup.processNextTick.process._tickCallback (node.js:244:9)

But, if you turn this feature on by setting

Q.longStackSupport = true;

then the above code gives a nice stack trace to the tune of

Error: boo!
    at explode (/path/to/test.js:3:11)
From previous event:
    at theDepthsOfMyProgram (/path/to/test.js:2:16)
    at Object.<anonymous> (/path/to/test.js:7:1)

Note how you can see the function that triggered the async operation in the stack trace! This is very helpful for debugging, as otherwise you end up getting only the first line, plus a bunch of Q internals, with no sign of where the operation started.

In node.js, this feature can also be enabled through the Q_DEBUG environment variable:

Q_DEBUG=1 node server.js

This will enable long stack support in every instance of Q.

This feature does come with somewhat-serious performance and memory overhead, however. If you're working with lots of promises, or trying to scale a server to many users, you should probably keep it off. But in development, go for it!

Tests

You can view the results of the Q test suite in your browser!

License

Copyright 2009–2017 Kristopher Michael Kowal and contributors MIT License (enclosed)

Comments
  • New plan for building Q from CommonJS

    New plan for building Q from CommonJS

    See #317 and #313 for previous discussions and results. Let's get this on record. Here's what I recall from discussion with @kriskowal:

    q.js in the root is in CommonJS format

    Produce:

    • release/q.amd.js
    • release/q.global.js
    • release/q.montage.js
    • release/q.ses.js

    Also:

    • Make volo happy by adding the appropriate package.json value per https://github.com/kriskowal/q/pull/317#issuecomment-19485482.

    Open questions:

    • Minified versions of some or all of these?
    • Commit these to source control or auto-upload them to S3 via Travis integration, as per the strategy at https://github.com/tildeio/rsvp.js/commit/ea2263764439df4569ff4efd9a80c87ccdb3184a ?
    opened by domenic 40
  • .done() and .ndone() [was: A useful short-cut for express.js]

    .done() and .ndone() [was: A useful short-cut for express.js]

    I have been using Q promises with express.js a lot lately, and I'm therefore terminating all promise chains with:

    .fail(next).end();
    

    This is because express.js says to pass all unhandled exceptions to next. The end is still necessary in case next throws an exception, which we'd want to just throw globally and exit the program.

    It would be really nice if this could become:

    .end(next);
    

    Which would just be a shorthand for the first thing?

    feature 
    opened by ForbesLindesay 33
  • Throw in promise-fulfillment swallows exception

    Throw in promise-fulfillment swallows exception

    <html>
    <head>
    <script src="../../lib/q/q.js"></script>
    <script>
    
    // Accept a promise for load, and report the success or failure of the load
    function foo(loaded) {
     return Q.when(
       loaded, 
       function glory(loaded){
         // Ooops the processing of success path fails!
         throw new Error("You lose");
         console.log("We have ", loaded);
       }, 
       function fail(err) {
         console.error("We have "+err);
       }
     );
    };
    
    // Create a promise for a load
    function promiseLoaded() {
      var defer = Q.defer();
      window.addEventListener(
        'load', 
        function(event) {
          defer.resolve("success");
        }, 
        false
      );
      return defer.promise;
    }
    
    function main() {
      // foo returns a promise, but we don't look at the return so we lose.
      foo(promiseLoaded());
    }
    
    main();
    </script>
    </head>
    <body>
    <h1>Bad developer ergonomics: throw in promise fulfillment swallows exception</h1>
    <p>May be related to <a href="https://github.com/kriskowal/q/issues/23">Issue 23 on github q</a>
    </body>
    </html>
    
    error-tracking 
    opened by johnjbarton 33
  • feat(finally): finally should receive as parameter the state of the promise

    feat(finally): finally should receive as parameter the state of the promise

    As per https://github.com/angular/angular.js/issues/9246 , it would be nice and more developer friendly to be able to receive the state of the promise inside the finally call.

    My suggestion is for .fin() to receive 2 parameters:

    1. a boolean -- if the promise was resolved (TRUE) or rejected (FALSE)
    2. a mixed -- value sent to .resolve() or .reject()

    @kriskowal : what do you think?

    I'll post here the real use-case again. We have a SPA and we are using AngularJS as a framework. I know Q service is a bit different than AngularJS $q, but the logic seems to be very similar.

    Our use-case is when all the ajax requests (error or success) may contain a set of messages - those messages should be automatically pushed to the messages component and be shown. The problem is that we have to write:

    .then(
      function (data) {
        msgService.notify(data);
      },
      function (data) {
        msgService.notify(data);
      }
    );
    
    
    My suggestion was to have something like:
    .then(...)
    .finally(function (isResolved, data) {
        msgService.notify(data);
    });
    

    We can even adapt our notify and just put ".finally(msgService.notify)".

    opened by dragosrususv 32
  • Documentation on 'flatten the pyramid'

    Documentation on 'flatten the pyramid'

    I am confused about the flatten the pyramid example, because what it does is execute every function with a value and a callback which is in fact the next iteration of then().

    But to actually do this, you have to return the functions contained by functions which cannot have any arguments, but the second argument is the callback.

    For example: return function(){withCB(arguments[1])} works but return function(err, cb){withCB(cb)} does not.

    Of course, this example is arbitrary. In reality the containing function would do some stuff before processing. For example making a mongodb query, and end with cursor.toArray(callback).

    Should this be added to the documentation/wiki or am I missing a point? Should the option to actually name the attributes in the function be added to Q, or am I missing a reason it's not?

    Also see Stack Overflow: Node.js Q promises, why use defer() when you can use this()?

    opened by Redsandro 32
  • Introduce `promise.inspect` and `Q.allSettled`

    Introduce `promise.inspect` and `Q.allSettled`

    These replace promise.valueOf and Q.allResolved, respectively. See API proposals in #256 and #257.

    The old methods are left as deprecated.

    The last issue regards the fate of Q.nearer. I think I broke it, but IIRC we wanted to do it differently anyway (e.g. always return a promise). Thoughts?

    opened by domenic 28
  • Support Node.js domains

    Support Node.js domains

    Some helpful comments from @mikeal on a probable strategy for supporting domains. This would help, from what I understand, in two situations:

    1. Putting exceptions thrown by .done() into the current domain.
    2. When an event emitter or other domain-using callback library is used inside a fulfillment or rejection handler, and throws an error, it would escape Q but wouldn't escape the domain. E.g.
    return Q.resolve().then(function () {
        doSomethingAsyncWithoutPromises(function (err, whatever) {
            // Q doesn't catch this, but domains would if we wired it up right.
            callANonexistantFunction();
        });
    });
    
    error-tracking 
    opened by domenic 24
  • Multi-yield for Q.async?

    Multi-yield for Q.async?

    Within a Q.asynced function, could we allow:

    yield [asyncOp1(), asyncOp2(), asyncOp3()];
    

    as a convenient short-hand for:

    yield Q.all([asyncOp1(), asyncOp2(), asyncOp3()]);
    

    It seems like this is a very common operation and the proposed new syntax is intuitive and reduces line-noise considerably.

    Technically, this would be backwards-incompatible as currently within a Q.asynced function, you can use x = yield y; for a non-promise value y and the value will pass through unchanged (after some hoops and jumps) to x. I'm not sure anyone does this however.

    opened by ndkrempel 23
  • Misleading warning about unhandled failure

    Misleading warning about unhandled failure

    q.js is always outputting [Q] Unhandled rejection reasons (should be empty) regardless of whether a failure handler is provided.

    Here is my code:

        "use strict";
        return Q.try(function()
        {
            return AjaxWithRetry.ajax(
                {
                    url: this.participants,
                    type: "POST",
                    data: JSON.stringify(
                        {
                            "user": user
                        }),
                    contentType: "application/vnd.com.foo.user+json; version=1; charset=utf-8"
                }).
                then(function(result)
                {
                    var settings = result.settings;
                    var xhr = result.xhr;
                    throw new ConflictingResourceException(settings.type, settings.url, xhr.responseText,
                        xhr.getResponseHeader("location"));
                },
                    function(value)
                    {
                        log.debug("0: " + value);
                        throw value;
                    }).catch(function(value)
            {
                log.debug("0.1: " + value);
                throw value;
            });
        }.bind(this));
    

    When I run this code, I see the following events:

    [Q] Unhandled rejection reasons (should be empty): 
    ["(no stack) ConflictingResourceException: POST http…rticipant: http://localhost:8080/participants/85/"]
    0.1: ConflictingResourceException: POST http://localhost:8080/calls/1/participants/ returned: Conflict with existing participant: http://localhost:8080/participants/85/ log4javascript.js:155
    

    Meaning, Q complains about an unhandled failure, even though the failure handler is invoked a second later. In the above example AjaxWithRetry invokes JQuery's ajax() method, and returns a Promise.

    opened by cowwoc 22
  • Bad performance?

    Bad performance?

    Hello, I was noticing some slow down in my application recently. Among other things we switched to using q heavily. I wasn't sure what the problem was, so I wrote a micro-benchmark for a couple of the libraries that we use that are core to our application.

    I am not sure if the following is valid, maybe someone can comment. If it is valid, it seems to me that there is a real problem in the q library that should be addressed as the results I am getting are at least 10-100x slower than I would have expected.

    
    q = require 'q'
    
    chain = (p, val) ->
      p.then -> val
    
    doit = ->
        original = q.defer()
        p = original.promise
        count = 0
        p = chain p, count until ++count >= 5
        original.resolve 'foo'
    
    count = 0
    max = 10000
    start = new Date().getTime()
    doit() until ++count >= max
    end = new Date().getTime()
    elapsed = end - start
    console.log "took #{elapsed} ms average ", count / (elapsed / 1000), " TPS"
    
    

    After running this several times, I get consistently the following results (my machine is recent model MacBook Air with a Core i7 2GHz processor):

    took 7214 ms average 1386.193512614361 macro TPS 6930.967563071805 micro TPS

    More troublesome than the result is the huge pause I get after printing out the data which indicates to me a big consumption of memory.

    Maybe I am doing something wrong that someone would like to point out?

    (To put things in perspective, I wrote a similar benchmark for the postal.js library, and the results there are about 35x faster to deliver 5,000 messages, about 20ms. Obviously postal and q are apples and oranges, but for pure in-memory operations, I surely did not expect operations to take so long, even if we account for a 5x increase)

    performance 
    opened by tsgautier 22
  • Handled rejected promises are claimed as unhandled in some cases

    Handled rejected promises are claimed as unhandled in some cases

    Handled rejected promises are claimed as unhandled in some cases. Can be reproduced with example like this:

    var QFS = require('q-io/fs');
    
    QFS.lastModified('/nonexistent')
    .fail(function(err) {
        console.log('error caught!');
    });
    

    This code will generate a warning on application exist. Seems to be related directly to Q, not Q-IO.

    error-tracking 
    opened by scf2k 20
  • Why return function ref ?

    Why return function ref ?

    Now, we need to start altering our "then" methods so that they return promises for the return value of their given callback. The "ref" case is simple. We'll coerce the return value of the callback to a promise and return that immediately.

    var ref = function (value) {
        if (value && typeof value.then === "function")
            return value;
        return {
            then: function (callback) {
                return ref(callback(value));
            }
        };
    };
    

    I try only to use "return callback(value)", It doesn't seem to be a problem,Can you provide an example (" return callback(value) ")?
    Thanks.

    opened by indown 6
  • Minified release?

    Minified release?

    "A