Manejo de múltiples capturas en la cadena de promesas

Todavía soy bastante nuevo en las promesas y estoy usando bluebird actualmente, sin embargo, tengo un escenario en el que no estoy muy seguro de cómo lidiar mejor con él.

Entonces, por ejemplo, tengo una cadena de promesas dentro de una aplicación exprés como esta:

repository.Query(getAccountByIdQuery)
        .catch(function(error){
            res.status(404).send({ error: "No account found with this Id" });
        })
        .then(convertDocumentToModel)
        .then(verifyOldPassword)
        .catch(function(error) {
            res.status(406).send({ OldPassword: error });
        })
        .then(changePassword)
        .then(function(){
            res.status(200).send();
        })
        .catch(function(error){
            console.log(error);
            res.status(500).send({ error: "Unable to change password" });
        });

Entonces el comportamiento que busco es:

• Va a obtener una cuenta por Id.
• Si hay un rechazo en este punto, bombardea y devuelve un error.
• Si no hay ningún error, convierta el documento devuelto a un modelo
• Verifique la contraseña con el documento de la base de datos
• Si las contraseñas no coinciden, bombardear y devolver un error diferente
• Si no hay error, cambie las contraseñas
• Entonces devuelve el éxito
• Si algo más salió mal, devuelva 500

Entonces, las capturas actualmente no parecen detener el encadenamiento, y eso tiene sentido, así que me pregunto si hay una manera de forzar de alguna manera la cadena a detenerse en un cierto punto en función de los errores, o si hay una manera mejor para estructurar esto para obtener alguna forma de comportamiento de ramificación, como es el caso de if X do Y else Z.

Cualquier ayuda sería genial.

Este comportamiento es exactamente como un lanzamiento sincrónico:

try{
    throw new Error();
} catch(e){
    // handle
} 
// this code will run, since you recovered from the error!

Eso es la mitad del objetivo .catch: poder recuperarse de los errores. Podría ser deseable volver a lanzar para indicar que el estado sigue siendo un error:

try{
    throw new Error();
} catch(e){
    // handle
    throw e; // or a wrapper over e so we know it wasn't handled
} 
// this code will not run

Sin embargo, esto por sí solo no funcionará en su caso ya que el error será detectado por un controlador posterior. El problema real aquí es que los manejadores de errores "MANEJAR CUALQUIER COSA" generalizados son una mala práctica en general y están muy mal vistos en otros lenguajes de programación y ecosistemas. Por esta razón, Bluebird ofrece capturas con tipo y predicado.

La ventaja adicional es que su lógica de negocios no tiene (y no debería) tener que ser consciente del ciclo de solicitud / respuesta en absoluto. No es responsabilidad de la consulta decidir qué estado HTTP y qué error obtiene el cliente y, más adelante, a medida que su aplicación crezca, es posible que desee separar la lógica empresarial (cómo consultar su base de datos y cómo procesar sus datos) de lo que envía al cliente. (qué código de estado http, qué texto y qué respuesta).

Así es como escribiría su código.

Primero, podría .Querylanzar una NoSuchAccountErrorsubclase Promise.OperationalErrorque Bluebird ya proporciona. Si no está seguro de cómo subclasificar un error, hágamelo saber.

También lo subclasificaría AuthenticationErrory luego haría algo como:

function changePassword(queryDataEtc){ 
    return repository.Query(getAccountByIdQuery)
                     .then(convertDocumentToModel)
                     .then(verifyOldPassword)
                     .then(changePassword);
}

Como puede ver, está muy limpio y puede leer el texto como un manual de instrucciones de lo que sucede en el proceso. También está separado de la solicitud / respuesta.

Ahora, lo llamaría desde el controlador de ruta como tal:

 changePassword(params)
 .catch(NoSuchAccountError, function(e){
     res.status(404).send({ error: "No account found with this Id" });
 }).catch(AuthenticationError, function(e){
     res.status(406).send({ OldPassword: error });
 }).error(function(e){ // catches any remaining operational errors
     res.status(500).send({ error: "Unable to change password" });
 }).catch(function(e){
     res.status(500).send({ error: "Unknown internal server error" });
 });

De esta manera, la lógica está en un solo lugar y la decisión de cómo manejar los errores para el cliente está en un solo lugar y no se enredan entre sí.

.catchfunciona como la try-catchdeclaración, lo que significa que solo necesita una captura al final:

repository.Query(getAccountByIdQuery)
        .then(convertDocumentToModel)
        .then(verifyOldPassword)
        .then(changePassword)
        .then(function(){
            res.status(200).send();
        })
        .catch(function(error) {
            if (/*see if error is not found error*/) {
                res.status(404).send({ error: "No account found with this Id" });
            } else if (/*see if error is verification error*/) {
                res.status(406).send({ OldPassword: error });
            } else {
                console.log(error);
                res.status(500).send({ error: "Unable to change password" });
            }
        });

Me pregunto si hay una manera de forzar de alguna manera a la cadena a detenerse en un punto determinado según los errores.

No. Realmente no puedes "terminar" una cadena, a menos que lances una excepción que burbujee hasta el final. Vea la respuesta de Benjamin Gruenbaum para saber cómo hacer eso.

Una derivación de este patrón no sería distinguir tipos de error, sino utilizar errores que tienen statusCodey bodycampos que pueden enviarse desde un solo .catchcontrolador genérico . Sin embargo, dependiendo de la estructura de su aplicación, su solución podría ser más limpia.

o si hay una mejor manera de estructurar esto para obtener algún tipo de comportamiento de ramificación

Sí, puedes ramificar con promesas . Sin embargo, esto significa dejar la cadena y "volver" al anidamiento, tal como lo haría en una declaración anidada if-else o try-catch:

repository.Query(getAccountByIdQuery)
.then(function(account) {
    return convertDocumentToModel(account)
    .then(verifyOldPassword)
    .then(function(verification) {
        return changePassword(verification)
        .then(function() {
            res.status(200).send();
        })
    }, function(verificationError) {
        res.status(406).send({ OldPassword: error });
    })
}, function(accountError){
    res.status(404).send({ error: "No account found with this Id" });
})
.catch(function(error){
    console.log(error);
    res.status(500).send({ error: "Unable to change password" });
});

Lo he estado haciendo de esta manera:

Dejas tu captura al final. Y arroje un error cuando suceda en la mitad de su cadena.

    repository.Query(getAccountByIdQuery)
    .then((resultOfQuery) => convertDocumentToModel(resultOfQuery)) //inside convertDocumentToModel() you check for empty and then throw new Error('no_account')
    .then((model) => verifyOldPassword(model)) //inside convertDocumentToModel() you check for empty and then throw new Error('no_account')        
    .then(changePassword)
    .then(function(){
        res.status(200).send();
    })
    .catch((error) => {
    if (error.name === 'no_account'){
        res.status(404).send({ error: "No account found with this Id" });

    } else  if (error.name === 'wrong_old_password'){
        res.status(406).send({ OldPassword: error });

    } else {
         res.status(500).send({ error: "Unable to change password" });

    }
});

Sus otras funciones probablemente se verían así:

function convertDocumentToModel(resultOfQuery) {
    if (!resultOfQuery){
        throw new Error('no_account');
    } else {
    return new Promise(function(resolve) {
        //do stuff then resolve
        resolve(model);
    }                       
}

Probablemente un poco tarde para la fiesta, pero es posible anidar .catchcomo se muestra aquí:

Red de desarrolladores de Mozilla: uso de promesas

Editar: envié esto porque proporciona la funcionalidad solicitada en general. Sin embargo, no es así en este caso particular. Porque como ya han explicado en detalle otros, .catchse supone que se recupera el error. No puede, por ejemplo, enviar una respuesta al cliente en múltiples .catch devoluciones de llamada porque un .catchsin explícito lo return resuelve con undefineden ese caso, lo que hace que el procedimiento se .thenactive aunque su cadena no esté realmente resuelta, lo que podría causar .catchque se activen y envíen seguidores. otra respuesta al cliente, provocando un error y probablemente arrojándose a UnhandledPromiseRejectionsu manera. Espero que esta enrevesada frase tenga algún sentido para ti.

En lugar de lo .then().catch()...que puede hacer .then(resolveFunc, rejectFunc). Esta cadena de promesas sería mejor si manejara las cosas en el camino. Así es como lo reescribiría:

repository.Query(getAccountByIdQuery)
    .then(
        convertDocumentToModel,
        () => {
            res.status(404).send({ error: "No account found with this Id" });
            return Promise.reject(null)
        }
    )
    .then(
        verifyOldPassword,
        () => Promise.reject(null)
    )
    .then(
        changePassword,
        (error) => {
            if (error != null) {
                res.status(406).send({ OldPassword: error });
            }
            return Promise.Promise.reject(null);
        }
    )
    .then(
        _ => res.status(200).send(),
        error => {
            if (error != null) {
                console.error(error);
                res.status(500).send({ error: "Unable to change password" });
            }
        }
    );

Nota: El if (error != null)es un poco de un truco para interactuar con el error más reciente.

Creo que la respuesta de Benjamin Gruenbaum anterior es la mejor solución para una secuencia lógica compleja, pero aquí está mi alternativa para situaciones más simples. Solo uso una errorEncounteredbandera junto con return Promise.reject()para omitir cualquier declaración theno subsiguiente catch. Entonces se vería así:

let errorEncountered = false;
someCall({
  /* do stuff */
})
.catch({
  /* handle error from someCall*/
  errorEncountered = true;
  return Promise.reject();
})
.then({
  /* do other stuff */
  /* this is skipped if the preceding catch was triggered, due to Promise.reject */
})
.catch({
  if (errorEncountered) {
    return;
  }
  /* handle error from preceding then, if it was executed */
  /* if the preceding catch was executed, this is skipped due to the errorEncountered flag */
});

Si tiene más de dos pares then / catch, probablemente debería usar la solución de Benjamin Gruenbaum. Pero esto funciona para una configuración simple.

Tenga en cuenta que la final catchsolo tiene en return;lugar de return Promise.reject();, porque no hay ninguna subsecuente thenque debamos omitir, y contaría como un rechazo de Promesa no manejado, lo que a Node no le gusta. Como está escrito arriba, la final catchdevolverá una Promesa resuelta pacíficamente.