Hi David, thanks for your thoughtful post. I've always used the two-arg
form of .then[1], but your post makes a strong case for more often using
separate one-arg .then and .fail calls. I say only more often because the
two arg form can easily make distinctions that the one-arg forms cannot
On Fri, Nov 9, 2012 at 4:33 AM, David Bruant bruan...@gmail.com wrote:
Hi,
In this message, I'll be sharing some experience I've had with the Q
library. I have worked with it for about 7-8 months in a medium/big Node.js
application (closed source, so I can't link, sorry).
I'll be covering
Both then and fail return another promise for the result of the callback
var someData1P = query(q1);
var processedDataP = someData1P.then(function first(data){
return process(data); // if what's returned here is a promise
P, then
// processedDataP will be a promise for
On Fri, Nov 9, 2012 at 9:01 AM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Fri, Nov 9, 2012 at 4:33 AM, David Bruant bruan...@gmail.com wrote:
Hi,
In this message, I'll be sharing some experience I've had with the Q
library. I have worked with it for about 7-8 months in a
From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On
Behalf Of Mark S. Miller
Sent: Friday, November 9, 2012 08:33
Hi David, thanks for your thoughtful post. I've always used the two-arg form
of .then[1], but your post makes a strong case for more often using
We have found this to be more expressive as well. Especially in ES5
environments, where we can use Q's alias of `catch` instead of `fail`:
p1.then(val = doStuff)
.catch(err = console.error(err));
Nice: +1
However, I see a lot of value in when as a word still. Then makes
sense when
The recent promise discussion prompted me to recall the following
musing/proposal from Kris Kowal:
https://github.com/kriskowal/q/wiki/On-Exceptions
In short, there's a common code pattern that you can do with promises that you
can't do with synchronous code. The proposal is for a language
The following should work? Finally expects a block statement, so need to
wrap it in { }...
var info, processed;
try {
info = JSON.parse(json);
} catch (exception) {
console.log(Information JSON malformed.);
} finally { try {
processed = process(info);
} catch (exception) {
The idea is to not do the processing if the JSON parsing fails.
From: Cryptic Swarm [mailto:crypticsw...@gmail.com]
Sent: Friday, November 9, 2012 11:55
To: Domenic Denicola
Cc: es-discuss@mozilla.org
Subject: Re: then
The following should work? Finally expects a block statement, so need to wrap
On Fri, Nov 9, 2012 at 11:57 AM, Domenic Denicola
dome...@domenicdenicola.com wrote:
The idea is to not do the processing if the JSON parsing fails.
** **
*From:* Cryptic Swarm [mailto:crypticsw...@gmail.com]
*Sent:* Friday, November 9, 2012 11:55
*To:* Domenic Denicola
*Cc:*
|
| The idea is to not do the processing if the JSON parsing fails.
|
Then, why not just nest your try's? For readability reasons?
var info, processed;
try {
info = JSON.parse(json);
try {
processed = process(info);
} catch(ex) {
...
}
p1.then(val = doStuff)
.catch(err = console.error(err));
Nice: +1
On further thought, I'm not so sure. Consider this code, which creates a
directory if it doesn't already exist and then logs done.
return AFS.stat(path).then(stat = {
if (!stat.isDirectory())
Another idea: log such transformed errors, or automate matching of handled failed promises
against generated failed promises.
What we really need, as mentioned by Kris Kowal on Twitter recently, is the ability to
*un*-console.log something. That is, we want to log unhandled rejections for the
David Bruant wrote:
Personally, to synchronize different async operations, I've never read
code more elegant than what Q.all offers.
What about task.js's join?
https://github.com/mozilla/task.js/blob/master/examples/read.html#L41
Generators + promises = tasks ;-).
/be
Kevin Smith wrote:
I think arrow functions make the two-arg form considerably more
aesthetically pleasing.
Agreed. The single-parameter name can help avoid the anonymous
functions separated by comma problem too.
/be
___
es-discuss mailing list
Hi all,
I thought it might be helpful to compile a list of terms that different
libraries and languages are using for promises.
In general, we need two terms: one to describe an object which can set the
state of the eventual, and one to describe an object which can only read
the eventual.
This
It seems important to me that one can easily see the connection between the two
terms. I don’t see it for Deferred and Promise. I do kind of see it for Promise
and Future. Can we do better? Not there yet, but something like PromiseMaker
and Promise.
On Nov 10, 2012, at 4:56 , Kevin Smith
17 matches
Mail list logo
