[Dojo-interest] Rejecting a Promise in then

Jan Dockx jandockx at gmail.com
Wed Apr 24 15:55:41 EDT 2013


Thx a lot David, Kenneth.

Jan Dockx
Fouten zijn niet mijn schuld, maar die van de iPad.


Op 24-apr.-2013 om 14:45 heeft "Kenneth G. Franqueiro" <kgf at dojotoolkit.org> het volgende geschreven:

> Yes, the moment an error callback is encountered, it is considered
> capable of "handling" the error, and puts the promise back on the
> "success" path.  If you want to continue further down the error path,
> re-throw the error within that errback.
> 
> Similarly, if you want to "switch tracks" to the error path from a
> callback, throw an error there as well.  Realize though that this will
> switch to the subsequent errback in the chain, not the errback that is
> "parallel" to the callback.  e.g. using your example (see added comment
> lines):
> 
> var aSecondPromise = aFirstPromise.then(
>  function(data) {
>    // If an error is thrown here...
>    return handleFirst(data);
>  },
>  function(err) {
>    ?XXXXXXXX?
>  }
> );
> aSecondPromise.then(
>  function(data) {
>    return handleSecond(data);
>  },
>  function(err) {
>    // ... then this will be called next.
>    ?YYYYYYYY?
>  }
> );
> 
> You're right that this unfortunately doesn't seem to be documented
> clearly anywhere.  There was actually a blog post several years ago,
> written about the old dojo/_base/Deferred (i.e. prior to 1.5), which had
> a very helpful diagram; while dojo/Deferred differs in its APIs (mainly
> in that addCallback/addErrback mutate the deferred while then does not),
> the flow between callbacks/errbacks of the diagram should still hold
> true: http://www.sitepen.com/blog/2009/03/31/queued-demystifying-deferreds/
> 
> --Ken
> 
> On 4/24/2013 5:30 AM, Jan Dockx wrote:
>> I just encountered an interesting problem, and found out that something
>> important is not documented with regards to Promises.
>> What I encountered was an error that turns up as argument value in the
>> callback, not the errback.
>> 
>> Note that we are working with Promises, not Deferreds.
>> 
>> var aSecondPromise = aFirstPromise.then(
>>  function(data) {
>>    return handleFirst(data);
>>  },
>>  function(err) {
>>    ?XXXXXXXX?
>>  }
>> );
>> aSecondPromise.then(
>>  function(data) {
>>    return handleSecond(data);
>>  },
>>  function(err) {
>>    ?YYYYYYYY?
>>  }
>> );
>> 
>> Suppose aFirstPromise resolves nominally. It is clearly documented that
>> in that case with the above code aSecondPromise will also resolve
>> nominally with the return value of the callback of the first then, i.e.,
>> handleFirst(data).
>> 
>> Nowhere in the documentation I can find the following cases however:
>> 
>> * if callback or errback in the aFirstPromise.then throw an exception,
>> what happens to aSecondPromise?
>> * if aFirstPromise fails, the errback of the first then is called
>> ("?XXXXXXX?").
>> ** can I now make aSecondPromise resolve nominally ("I handled the
>> error")? by returning a nominal value in the errback?
>> ** how should I make sure aSecondPromise is rejected? My current issue
>> makes clear that returning a value (in casu "err") does not always
>> result in a rejection of aSecondPromise. Should I throw something?
>> Should I return something of a specific type?
>> * if aFirstPromise resolves nominally, and the callback is called, how
>> can I reject aSecondPromise ("on closer inspection this data isn't good
>> enough")? Should I throw something? Should I return something of a
>> specific type?
>> 
>> 
>> 
>> 
>> 
>> /"I've got to ask you," I say. "How long do you envision this rule of
>> the universe to be?"/
>> /"I'm guessing it's really very short."/
>> /"Like how long?"/
>> /"I don't know. In Mathematica, for example, perhaps three, four lines
>> of code."/
>> /"Four lines of code?"/
>> /"/[...]/ it will be short if Mathematica was a well-designed language.
>> It will be longer if it doesn't happen to be as well-designed, in the
>> sense that that doesn't happen to be the way the universe works. But
>> we're not looking at 25,000 lines of code or something. We're looking at
>> a handful of lines of code."/
>> /"So it's not like Windows?"/
>> Stephen Wolfram, in an interview with Steven Levy;
>> The Man Who Cracked The Code to Everything ...; Wired; June 2002;
>> http://www.wired.com/wired/archive/10.06/wolfram.html
>> 
>> 
>> 
>> 
>> 
>> 
>> ________________________________________________________
>> Dojo Toolkit: http://dojotoolkit.org/
>> Tutorials: http://dojotoolkit.org/documentation/
>> Reference Guide: http://dojotoolkit.org/reference-guide
>> API Documentation: http://dojotoolkit.org/api
>> 
>> Dojo-interest at mail.dojotoolkit.org
>> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
> ________________________________________________________
> Dojo Toolkit: http://dojotoolkit.org/
> Tutorials: http://dojotoolkit.org/documentation/
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> 
> Dojo-interest at mail.dojotoolkit.org
> To unsubscribe, visit: http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest


More information about the Dojo-interest mailing list