Top Related Projects
:bird: :zap: Bluebird is a full featured promise library with unmatched performance.
Bare bones Promises/A+ implementation
Async utilities for node and the browser
Run multiple promise-returning & async functions with limited concurrency
Promise queue with concurrency control
Quick Overview
Q is a promise library for JavaScript that helps manage asynchronous operations. It provides a powerful and flexible way to handle callbacks, making it easier to write and maintain asynchronous code. Q is particularly useful for managing complex chains of asynchronous operations and error handling.
Pros
- Simplifies asynchronous programming by providing a consistent and intuitive API
- Supports both Node.js and browser environments
- Offers advanced features like promise chaining, error propagation, and parallel execution
- Well-documented and widely adopted in the JavaScript community
Cons
- Performance overhead compared to native promises or simpler promise libraries
- Learning curve for developers new to promise-based programming
- Some consider it outdated compared to more modern alternatives like native promises or async/await
- Large file size compared to lighter promise implementations
Code Examples
Creating and resolving a promise:
const Q = require('q');
const promise = Q.fcall(() => {
return "Hello, Q!";
});
promise.then(result => {
console.log(result); // Output: Hello, Q!
});
Chaining promises:
Q.fcall(() => {
return 5;
})
.then(result => {
return result * 2;
})
.then(result => {
console.log(result); // Output: 10
})
.catch(error => {
console.error("An error occurred:", error);
});
Parallel execution with Q.all:
const promise1 = Q.delay(1000).then(() => "First");
const promise2 = Q.delay(500).then(() => "Second");
Q.all([promise1, promise2])
.then(results => {
console.log(results); // Output: ["First", "Second"]
})
.catch(error => {
console.error("An error occurred:", error);
});
Getting Started
To use Q in your project, first install it via npm:
npm install q
Then, in your JavaScript file:
const Q = require('q');
// Create a deferred object
const deferred = Q.defer();
// Resolve the promise after 1 second
setTimeout(() => {
deferred.resolve("Promise resolved!");
}, 1000);
// Use the promise
deferred.promise.then(result => {
console.log(result); // Output: Promise resolved!
}).catch(error => {
console.error("An error occurred:", error);
});
This example demonstrates creating a deferred object, resolving it after a delay, and handling the result with a promise.
Competitor Comparisons
:bird: :zap: Bluebird is a full featured promise library with unmatched performance.
Pros of Bluebird
- Significantly faster performance in most scenarios
- More extensive feature set, including advanced error handling and utility methods
- Better browser support, especially for older versions
Cons of Bluebird
- Larger file size, which may impact load times in browser environments
- Steeper learning curve due to its more comprehensive API
- Less focus on simplicity compared to Q's minimalist approach
Code Comparison
Q:
Q.fcall(function () {
return "hello world";
}).then(function (result) {
console.log(result);
});
Bluebird:
Promise.resolve().then(function () {
return "hello world";
}).then(function (result) {
console.log(result);
});
Key Differences
- Bluebird offers more optimization techniques and performance enhancements
- Q focuses on simplicity and ease of use, with a smaller API surface
- Bluebird provides more granular control over promise behavior and chaining
- Q has better integration with older callback-based APIs
Use Cases
- Choose Bluebird for performance-critical applications or when advanced features are needed
- Opt for Q in simpler projects or when working with legacy systems that require callback support
Community and Maintenance
- Bluebird has a larger and more active community
- Q has been around longer but has seen less frequent updates in recent years
Bare bones Promises/A+ implementation
Pros of then/promise
- Lighter weight and more focused on core Promise functionality
- Simpler API with fewer methods, potentially easier to learn
- Closer to the native Promise implementation in modern JavaScript
Cons of then/promise
- Less comprehensive feature set compared to Q
- Fewer utility methods for advanced Promise manipulation
- May require additional libraries or custom code for some complex scenarios
Code Comparison
Q:
Q.fcall(function () {
return 10;
})
.then(function (result) {
console.log(result);
});
then/promise:
Promise.resolve(10)
.then(function (result) {
console.log(result);
});
Summary
then/promise is a more lightweight and focused Promise library, while Q offers a more comprehensive set of features and utilities. then/promise may be preferable for projects that prioritize simplicity and closeness to native Promises, while Q might be better suited for complex applications requiring advanced Promise manipulation and additional utilities. The choice between the two depends on the specific needs of the project and the developer's preferences for API design and feature set.
Async utilities for node and the browser
Pros of Async
- Lightweight and focused on asynchronous JavaScript utilities
- Extensive collection of async control flow functions
- Widely adopted and battle-tested in production environments
Cons of Async
- Limited to Node.js environment, not suitable for browser use
- Lacks advanced features like cancellation and progress tracking
- Callback-based API can lead to callback hell in complex scenarios
Code Comparison
Async example:
async.waterfall([
function(callback) {
callback(null, 'one', 'two');
},
function(arg1, arg2, callback) {
callback(null, 'three');
},
function(arg1, callback) {
callback(null, 'done');
}
], function (err, result) {
console.log(result);
});
Q example:
Q.fcall(function () {
return 'one';
})
.then(function (result) {
return result + ' two';
})
.then(function (result) {
return result + ' three';
})
.done(function (result) {
console.log(result);
});
Both libraries aim to simplify asynchronous programming in JavaScript, but they take different approaches. Async focuses on providing utility functions for managing asynchronous control flow, while Q implements Promises/A+ specification and offers a more comprehensive solution for asynchronous programming, including features like promise chaining and error handling.
Run multiple promise-returning & async functions with limited concurrency
Pros of p-limit
- Lightweight and focused on a single task (limiting concurrency)
- Modern JavaScript syntax and Promise-based API
- Actively maintained with recent updates
Cons of p-limit
- Limited functionality compared to Q's more comprehensive feature set
- Lacks advanced features like promise chaining and error handling
Code Comparison
p-limit:
import pLimit from 'p-limit';
const limit = pLimit(2);
const input = [1, 2, 3, 4, 5];
Promise.all(input.map(i => limit(() => fetchSomething(i))));
Q:
var Q = require('q');
Q.all([
Q.fcall(fetchSomething, 1),
Q.fcall(fetchSomething, 2),
Q.fcall(fetchSomething, 3)
]);
Summary
p-limit is a focused tool for managing concurrency in modern JavaScript applications, while Q is a more comprehensive promise library with a wider range of features. p-limit is lighter and more specialized, making it a good choice for projects that only need concurrency control. Q, on the other hand, offers a broader set of tools for working with promises and asynchronous operations, but may be considered outdated compared to newer alternatives.
Promise queue with concurrency control
Pros of p-queue
- Focused on queue management with priority and concurrency control
- Actively maintained with regular updates and improvements
- Lightweight and easy to integrate into modern JavaScript projects
Cons of p-queue
- Limited to queue functionality, not a full-featured promise library
- May require additional setup for complex promise chains or error handling
- Less comprehensive documentation compared to Q
Code Comparison
p-queue:
import PQueue from 'p-queue';
const queue = new PQueue({concurrency: 2});
await queue.add(() => fetchSomething());
await queue.add(() => fetchSomethingElse());
Q:
var Q = require('q');
Q.fcall(fetchSomething)
.then(fetchSomethingElse)
.then(function (result) {
console.log(result);
});
Summary
p-queue is a modern, focused library for managing asynchronous task queues with priority and concurrency control. It's well-suited for specific use cases where queue management is the primary concern. Q, on the other hand, is a more comprehensive promise library with a wider range of features for managing asynchronous operations. While Q offers more flexibility, p-queue provides a simpler, more targeted solution for queue-based tasks in contemporary JavaScript environments.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Note
Please consider using JavaScript promises instead of Q. Native promises are faster, have better tooling support and are the future.
When work on Q began, promises were an academic novelty in JavaScript, unlikely to be adopted much less popular, though obviously full ofâ¦promise. Callbacks dominated the landscape. Q aimed to introduce a technology to JavaScript that had been proven and vetted in languages like E and Câ¯. With four years of incubation, evangelism, education, and feedback, promises became part of the language. Every modern browser contains a built-in Promise
implementation. Being able to influence the internet and working on a library used by millions of codebases was an exciting and humbling experience.
Q isn't going anywhere. The code is still here and bugs will be fixed but further development has been unnecessary for many years. We encourage you to read the code and the explainers to glimpse into the history of the internet.
Q
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 aQ
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)
Top Related Projects
:bird: :zap: Bluebird is a full featured promise library with unmatched performance.
Bare bones Promises/A+ implementation
Async utilities for node and the browser
Run multiple promise-returning & async functions with limited concurrency
Promise queue with concurrency control
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot