javascript - Node.js Abort chain in Q in different point -

i have pretty long chain of check in q, , interrupt when error rise:

i have looked how abort failing q promise in node.js , other answers on so, seems impossible me, can't exist nothing else.

example `

q().then(function(){     return q.ninvoke(myobject, 'save'); }).fail(functon(err){ // if error     res.status(400).send(err.message);// duplicate key }).then(function(){     add object object db referenced myobject }).fail(functon(err){ // if error     res.status(400).send(err.message);// connection error }).then(function(){     somethinng else }).done() 

`

obviously, if can't save first object, not go on through other steps, exit without throwing error , blocking execution of server without sending message client.

i tried add 2 function done(ok, rejected), ok() called. avoid chunking code in 3 different functions if possible.

as far can gather, don't need particularly tricky, understand how success , failure propagate through .then chain, exploit knowledge behaviour desire.

• the chain continue down "success" path long keep on having success
• the chain continue down "fail" path long keep on having failure
• if "success" function throws error or returns rejected promise, chain continue down "fail" path
• if "fail" function returns value or fulfilled promise, chain continue down "success" path.

this behaviour @ heart of promises/a+ standard.

if write chain single, terminal .fail, (if understand correctly) behaviour seek.

q().then(function () {     return q.ninvoke(myobject, 'save'); }).then(function () {     add object object db referenced myobject }).then(function () {     somethinng else }).fail(functon (err) {     res.status(400).send(err.message); }); 

here, failure @ point in .then chain cause propageted promise drop straight through rest of .thens , caught terminal .fail.

this has advantage on code in question, has multiple interwoven .fails. pattern can made work need introduce mechanism suppress multiple "fail" behaviour once failure has been handled. in unusual circumstances might appropriate, in general regarded messy.

the other thing might need in fail handler distiguish between different types of failure , act accordingly. that's pretty trivial formal variable err can tested, eg in switch-case structure. appear not need such test action on failure same in cases.