Promessas de JavaScript - rejeitar x lançar

Eu li vários artigos sobre esse assunto, mas ainda não está claro para mim se há uma diferença entre Promise.rejectvs. lançar um erro. Por exemplo,

Usando Promise.reject

return asyncIsPermitted()
    .then(function(result) {
        if (result === true) {
            return true;
        }
        else {
            return Promise.reject(new PermissionDenied());
        }
    });

Usando throw

return asyncIsPermitted()
    .then(function(result) {
        if (result === true) {
            return true;
        }
        else {
            throw new PermissionDenied();
        }
    });

Minha preferência é usar throwsimplesmente porque é mais curto, mas queria saber se existe alguma vantagem de uma sobre a outra.

Não há vantagem em usar um vs o outro, mas há um caso específico em throwque não funciona. No entanto, esses casos podem ser corrigidos.

Sempre que você estiver dentro de um retorno de chamada promissor, poderá usá-lo throw. No entanto, se você estiver em outro retorno de chamada assíncrono, deverá usar reject.

Por exemplo, isso não acionará a captura:

new Promise(function() {
  setTimeout(function() {
    throw 'or nah';
    // return Promise.reject('or nah'); also won't work
  }, 1000);
}).catch(function(e) {
  console.log(e); // doesn't happen
});

Em vez disso, você fica com uma promessa não resolvida e uma exceção não capturada. Esse é um caso em que você deseja usar reject. No entanto, você pode corrigir isso de duas maneiras.

1. usando a função de rejeição da promessa original dentro do tempo limite:

new Promise(function(resolve, reject) {
  setTimeout(function() {
    reject('or nah');
  }, 1000);
}).catch(function(e) {
  console.log(e); // works!
});

2. promisificando o tempo limite:

function timeout(duration) { // Thanks joews
  return new Promise(function(resolve) {
    setTimeout(resolve, duration);
  });
}

timeout(1000).then(function() {
  throw 'worky!';
  // return Promise.reject('worky'); also works
}).catch(function(e) {
  console.log(e); // 'worky!'
});

Outro fato importante é que reject() NÃO encerra o fluxo de controle como uma returninstrução. Em contraste throw, termina o fluxo de controle.

Exemplo:

new Promise((resolve, reject) => {
  throw "err";
  console.log("NEVER REACHED");
})
.then(() => console.log("RESOLVED"))
.catch(() => console.log("REJECTED"));

vs

new Promise((resolve, reject) => {
  reject(); // resolve() behaves similarly
  console.log("ALWAYS REACHED"); // "REJECTED" will print AFTER this
})
.then(() => console.log("RESOLVED"))
.catch(() => console.log("REJECTED"));

Sim, a maior diferença é que rejeitar é uma função de retorno de chamada que é executada após a promessa ser rejeitada, enquanto que o throw não pode ser usado de forma assíncrona. Se você optar por usar rejeitar, seu código continuará sendo executado normalmente de maneira assíncrona, enquanto o throw priorizará a conclusão da função de resolução (essa função será executada imediatamente).

Um exemplo que vi que ajudou a esclarecer o problema para mim foi que você pode definir uma função Timeout com rejeitar, por exemplo:

new Promise(_, reject) {
 setTimeout(reject, 3000);
});

Não foi possível escrever acima com throw.

No seu pequeno exemplo, a diferença é indistinguível, mas ao lidar com um conceito assíncrono mais complicado, a diferença entre os dois pode ser drástica.

TLDR: uma função é difícil de usar quando, às vezes, retorna uma promessa e às vezes gera uma exceção. Ao escrever uma função assíncrona, prefira sinalizar falha retornando uma promessa rejeitada

Seu exemplo em particular ofusca algumas distinções importantes entre eles:

Como você está manipulando erros dentro de uma cadeia de promessas, as exceções lançadas são convertidas automaticamente em promessas rejeitadas. Isso pode explicar por que eles parecem ser intercambiáveis ​​- eles não são.

Considere a situação abaixo:

checkCredentials = () => {
    let idToken = localStorage.getItem('some token');
    if ( idToken ) {
      return fetch(`https://someValidateEndpoint`, {
        headers: {
          Authorization: `Bearer ${idToken}`
        }
      })
    } else {
      throw new Error('No Token Found In Local Storage')
    }
  }

Isso seria um antipadrão, pois você precisaria oferecer suporte a casos de erro assíncrono e sincronizado. Pode parecer algo como:

try {
  function onFulfilled() { ... do the rest of your logic }
  function onRejected() { // handle async failure - like network timeout }
  checkCredentials(x).then(onFulfilled, onRejected);
} catch (e) {
  // Error('No Token Found In Local Storage')
  // handle synchronous failure
} 

Não é bom e é exatamente aqui que Promise.reject(disponível no escopo global) vem o resgate e se diferencia efetivamente throw. O refator passa a ser:

checkCredentials = () => {
  let idToken = localStorage.getItem('some_token');
  if (!idToken) {
    return Promise.reject('No Token Found In Local Storage')
  }
  return fetch(`https://someValidateEndpoint`, {
    headers: {
      Authorization: `Bearer ${idToken}`
    }
  })
}

Agora, você pode usar apenas um catch()para falhas de rede e a verificação de erro síncrono por falta de tokens:

checkCredentials()
      .catch((error) => if ( error == 'No Token' ) {
      // do no token modal
      } else if ( error === 400 ) {
      // do not authorized modal. etc.
      }

Um exemplo para experimentar. Apenas mude isVersionThrow para false para usar rejeitar em vez de lançar.

const isVersionThrow = true

class TestClass {
  async testFunction () {
    if (isVersionThrow) {
      console.log('Throw version')
      throw new Error('Fail!')
    } else {
      console.log('Reject version')
      return new Promise((resolve, reject) => {
        reject(new Error('Fail!'))
      })
    }
  }
}

const test = async () => {
  const test = new TestClass()
  try {
    var response = await test.testFunction()
    return response 
  } catch (error) {
    console.log('ERROR RETURNED')
    throw error 
  }  
}

test()
.then(result => {
  console.log('result: ' + result)
})
.catch(error => {
  console.log('error: ' + error)
})