Como rejeitar na sintaxe assíncrona / aguardar?

Como posso rejeitar uma promessa retornada por uma função assíncrona / aguardada?

por exemplo, originalmente

foo(id: string): Promise<A> {
  return new Promise((resolve, reject) => {
    someAsyncPromise().then((value)=>resolve(200)).catch((err)=>reject(400))
  });
}

Traduzir para assíncrono / aguardar

async foo(id: string): Promise<A> {
  try{
    await someAsyncPromise();
    return 200;
  } catch(error) {//here goes if someAsyncPromise() rejected}
    return 400; //this will result in a resolved promise.
  });
}

Então, como eu poderia rejeitar adequadamente essa promessa neste caso?

Sua melhor aposta é a de throwuma Errorembalagem o valor, o que resulta em uma promessa rejeitado com um Errorembrulho o valor:

} catch (error) {
    throw new Error(400);
}

Você também pode apenas throwo valor, mas não há informações de rastreamento de pilha:

} catch (error) {
    throw 400;
}

Como alternativa, retorne uma promessa rejeitada com um Errorempacotamento do valor, mas não é idiomático:

} catch (error) {
    return Promise.reject(new Error(400));
}

(Ou apenas return Promise.reject(400);, mas novamente, não há informações de contexto.)

(No seu caso, como você está usando TypeScripte fooo valor de retrn Promise<A>, você usaria return Promise.reject<A>(400 /*or error*/);)

Em uma situação async/ await, esse último provavelmente é um erro de correspondência semântica, mas funciona.

Se você joga um Error, isso funciona bem com qualquer coisa que consome o fooresultado da sua com awaitsintaxe:

try {
    await foo();
} catch (error) {
    // Here, `error` would be an `Error` (with stack trace, etc.).
    // Whereas if you used `throw 400`, it would just be `400`.
}

Provavelmente, também deve ser mencionado que você pode simplesmente encadear uma catch()função após a chamada de sua operação assíncrona, porque, sob o capô, uma promessa ainda é retornada.

await foo().catch(error => console.log(error));

Dessa forma, você pode evitar a try/catchsintaxe se não gostar.

Você pode criar uma função de wrapper que aceite uma promessa e retorne uma matriz com dados se não houver erro e o erro se houver um erro.

function safePromise(promise) {
  return promise.then(data => [ data ]).catch(error => [ null, error ]);
}

Use-o assim no ES7 e em uma função assíncrona :

async function checkItem() {
  const [ item, error ] = await safePromise(getItem(id));
  if (error) { return null; } // handle error and return
  return item; // no error so safe to use item
}

Uma maneira melhor de escrever a função assíncrona seria retornando uma promessa pendente desde o início e, em seguida, processando rejeições e resoluções no retorno de chamada da promessa, em vez de apenas citar uma promessa rejeitada por erro. Exemplo:

async foo(id: string): Promise<A> {
    return new Promise(function(resolve, reject) {
        // execute some code here
        if (success) { // let's say this is a boolean value from line above
            return resolve(success);
        } else {
            return reject(error); // this can be anything, preferably an Error object to catch the stacktrace from this function
        }
    });
}

Então você apenas encadeia métodos na promessa retornada:

async function bar () {
    try {
        var result = await foo("someID")
        // use the result here
    } catch (error) {
        // handle error here
    }
}

bar()

Fonte - este tutorial:

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

Tenho uma sugestão para lidar adequadamente com rejeições em uma nova abordagem, sem ter vários blocos try-catch.

import to from './to';

async foo(id: string): Promise<A> {
    let err, result;
    [err, result] = await to(someAsyncPromise()); // notice the to() here
    if (err) {
        return 400;
    }
    return 200;
}

Para onde a função to.ts deve ser importada de:

export default function to(promise: Promise<any>): Promise<any> {
    return promise.then(data => {
        return [null, data];
    }).catch(err => [err]);
}

Os créditos vão para Dima Grossman no link a seguir .

Esta não é uma resposta à pergunta de @TJ Crowder. Apenas um comentário respondendo ao comentário "E, na verdade, se a exceção for convertida em uma rejeição, não tenho certeza se estou realmente incomodado se for um Erro. ​​Minhas razões para lançar apenas o Erro provavelmente não se aplicam. "

se o seu código estiver usando async/ await, ainda é uma boa prática rejeitar com um em Errorvez de 400:

try {
  await foo('a');
}
catch (e) {
  // you would still want `e` to be an `Error` instead of `400`
}

Sei que essa é uma pergunta antiga, mas acabei de me deparar com o tópico e parece haver aqui uma confusão entre erros e rejeição que ocorre (em muitos casos, pelo menos) nos conselhos frequentemente repetidos de não usar o tratamento de exceções para lidar com casos previstos. Para ilustrar: se um método assíncrono está tentando autenticar um usuário e a autenticação falha, isso é uma rejeição (um dos dois casos previstos) e não um erro (por exemplo, se a API de autenticação não estiver disponível).

Para ter certeza de que não estava apenas dividindo os cabelos, executei um teste de desempenho com três abordagens diferentes, usando este código:

const iterations = 100000;

function getSwitch() {
  return Math.round(Math.random()) === 1;
}

function doSomething(value) {
  return 'something done to ' + value.toString();
}

let processWithThrow = function () {
  if (getSwitch()) {
    throw new Error('foo');
  }
};

let processWithReturn = function () {
  if (getSwitch()) {
    return new Error('bar');
  } else {
    return {}
  }
};

let processWithCustomObject = function () {
  if (getSwitch()) {
    return {type: 'rejection', message: 'quux'};
  } else {
    return {type: 'usable response', value: 'fnord'};
  }
};

function testTryCatch(limit) {
  for (let i = 0; i < limit; i++) {
    try {
      processWithThrow();
    } catch (e) {
      const dummyValue = doSomething(e);
    }
  }
}

function testReturnError(limit) {
  for (let i = 0; i < limit; i++) {
    const returnValue = processWithReturn();
    if (returnValue instanceof Error) {
      const dummyValue = doSomething(returnValue);
    }
  }
}

function testCustomObject(limit) {
  for (let i = 0; i < limit; i++) {
    const returnValue = processWithCustomObject();
    if (returnValue.type === 'rejection') {
      const dummyValue = doSomething(returnValue);
    }
  }
}

let start, end;
start = new Date();
testTryCatch(iterations);
end = new Date();
const interval_1 = end - start;
start = new Date();
testReturnError(iterations);
end = new Date();
const interval_2 = end - start;
start = new Date();
testCustomObject(iterations);
end = new Date();
const interval_3 = end - start;

console.log(`with try/catch: ${interval_1}ms; with returned Error: ${interval_2}ms; with custom object: ${interval_3}ms`);

Algumas das coisas que estão lá dentro estão incluídas por causa da minha incerteza em relação ao interpretador Javascript (eu só gosto de descer uma toca de coelho por vez); por exemplo, incluí a doSomethingfunção e designei seu retorno dummyValuepara garantir que os blocos condicionais não fossem otimizados.

Meus resultados foram:

with try/catch: 507ms; with returned Error: 260ms; with custom object: 5ms

Sei que existem muitos casos em que não vale a pena procurar pequenas otimizações, mas em sistemas de larga escala essas coisas podem fazer uma grande diferença cumulativa, e essa é uma comparação bastante clara.

ASSIM ... enquanto eu acho que a abordagem da resposta aceita é sólida nos casos em que você espera lidar com erros imprevisíveis em uma função assíncrona, nos casos em que uma rejeição significa simplesmente "você terá que seguir o plano B (ou C, ou D ...) "Acho que minha preferência seria rejeitar o uso de um objeto de resposta personalizado.