Czy mogę wcześnie przerwać łańcuch przy pomocy obietnic Bluebird?

Question

nie koniecznie chcą błędów, ale mam:

getFromDb().then (tradeData) -> 
    if not tradeData 
    # DO NOT CONTINUE THE CHAIN 
    else 
    getLatestPrice tradeData 
.then (latestPrice) -> 
    ... 
.then -> 
    ... 
.then -> 
    ... 
.catch (err) -> 
    next err 

żaden sposób dla mnie, aby przerwać łańcuch, jeśli nie ma tradeData?

Answer 1

getFromDb().then (tradeData) -> 
    if tradeData 
    getLatestPrice tradeData -> 
     .then (latestPrice) -> 
     ... 
     .then -> 
     ... 
     .then -> 
     ... 
     .catch (err) -> 
     next err 
    else 
    getSomethingElse -> 
     send("no data") 

w 3,0, będziesz w stanie to zrobić:

p = getFromDb().then (tradeData) -> 
    if not tradeData 
    send("no data"); 
    p.break() 
    else 
    getLatestPrice tradeData 
.then (latestPrice) -> 
    ... 
.then -> 
    ... 
.then -> 
    ... 
.catch (err) -> 
    next err 

Answer 2

Chociaż przyjętym odpowiedź, ale chciałbym powiedzieć wszystkim Googlersami że „przerwa()” funkcja została zmieniona do "cancel()"

używać coś takiego:

p = getFromDb().then (tradeData) -> 
    if not tradeData 
    send("no data"); 
    p.cancel(); // Look Here!!!!!!!!!!!!!!!! 
    else 
    getLatestPrice tradeData 
.then (latestPrice) -> 
    ... 
.then -> 
    ... 
.then -> 
    ... 
.catch (err) -> 
    next err 

Przedtem upewnij się, aby dodać następujące linie w C onfig:

Promise.config({ 
    cancellation: true 
}); 

Answer 3

Im po prostu zastanawiasz się, dlaczego nie biorąc korzyści z faktu, że można throw cokolwiek chcesz, a nie tylko coś, co jest instanceof Error. Uważa się to za złą praktykę? Moim zdaniem to zależy, zależy to od tego, co próbujesz osiągnąć. Łańcuch obietnicy może zostać przerwany z różnych powodów, ale ogólnie rzecz biorąc, te dwa przypadałyby na dwie grupy. Potrzebne są Classic error occur i early break in chain. Logicznie drugiego nie można uznać za coś, co powinno być instance of Error.

const handleError = (err) => { 
    ... 
} 

const skip = (reason, ..., ...) => { 
    /** 
    * construct whatever you like 
    * just for example here return reason 
    */ 
    return reason 
} 

Promise.resolve() 
.then(() => { 
    if (iShouldEndChainEarlier) { 
    throw skip('I would like to end chain earlier') 
    } 

    return asyncOperation1() 
}) 
.then(results => { 
    ... 
    return asyncOperation2(results) 
}) 
.then(... => { 
    ... 
}) 
.catch(interrupt => { 
    if (interrupt instanceof Error) { 
    return handleError(interrupt) 
    } 

    /** 
    * Handle breaking promise chain earlier 
    * having interrupt reason in scope 
    */ 
}) 

Jeśli logicznie, na początku przerwy w łańcuchu może być traktowane jako błąd (który może być całkowicie sprawę), można stworzyć swój własny błąd i rozróżniać dwa w catch bloku. Po prostu mówiąc, że można myśleć o innym podejściu (ach), gdy radzimy sobie z jakimkolwiek zakłóceniem, które może wystąpić w obiecującym łańcuchu.

Możemy argumentować, że można to uznać za coś przeciwko first error pattern w węźle. Jeśli wystąpi błąd, najlepszą praktyką będzie wywoływanie oddzwaniania, takiego jak callback(err), gdzie err naprawdę powinno być instanceof Error w innym przypadku callback(null, data). Ale z drugiej strony, mając na uwadze, że .catch(fn) jest dla mnie po prostu cukrem dla then(undefined, onRejected), wydaje się być wystarczająco dobry do obsłużenia parametru onRejected w zależności od sytuacji, w której się znajdujesz.