Jak odrzucić w składni asynchronicznej / oczekującej?

Jak mogę odrzucić obietnicę zwróconą przez funkcję asynchroniczną / oczekującą?

np. pierwotnie

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

Przetłumacz na async / czekaj

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.
  });
}

Jak mogę właściwie odrzucić tę obietnicę w tym przypadku?

Najprościej jest throww Erroropakowaniu wartość, co powoduje przerwanie obietnicy z Erroropakowania wartość:

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

Możesz także podać tylko throwwartość, ale wtedy nie ma informacji o śledzeniu stosu:

} catch (error) {
    throw 400;
}

Alternatywnie, zwróć odrzuconą obietnicę z Errorzawijaniem wartości, ale nie jest to idiomatyczne:

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

(Lub po prostu return Promise.reject(400);, ale znowu, wtedy nie ma informacji kontekstowych.)

(W twoim przypadku, gdy używasz, TypeScripta foowartość pobierana to Promise<A>, należy użyć return Promise.reject<A>(400 /*or error*/);)

W sytuacji async/ awaitto ostatnie jest prawdopodobnie semantycznym niedopasowaniem, ale działa.

Jeśli rzucisz an Error, to gra dobrze z czymkolwiek, co pochłania foowynik w awaitskładni:

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`.
}

Prawdopodobnie należy również wspomnieć, że można po prostu catch()połączyć funkcję po wywołaniu operacji asynchronicznej, ponieważ pod maską nadal jest zwracana obietnica.

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

W ten sposób możesz uniknąć try/catchskładni, jeśli Ci się nie podoba.

Możesz utworzyć funkcję opakowania, która przyjmuje obietnicę i zwraca tablicę z danymi, jeśli nie ma błędu, i błędem, jeśli wystąpił błąd.

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

Użyj tego w ES7 i w funkcji asynchronicznej :

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
}

Lepszym sposobem na napisanie funkcji asynchronicznej byłoby zwrócenie oczekującej obietnicy od początku, a następnie obsługa zarówno odrzucania, jak i rozstrzygania w ramach wywołania zwrotnego obietnicy, zamiast tylko wyrzucania odrzuconej obietnicy w przypadku błędu. Przykład:

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
        }
    });
}

Następnie po prostu połącz metody ze zwróconej obietnicy:

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

bar()

Źródło - ten samouczek:

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

Mam sugestię, aby właściwie obsługiwać odrzucenia w nowatorskim podejściu, bez posiadania wielu bloków 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;
}

Skąd należy importować funkcję to.ts :

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

Kredyty trafiają do Dimy Grossman pod poniższym linkiem .

To nie jest odpowiedź na odpowiedź @TJ Crowder. Po prostu komentarz odpowiadający na komentarz „I faktycznie, jeśli wyjątek zostanie przekształcony w odrzucenie, nie jestem pewien, czy tak naprawdę przeszkadza mi, jeśli jest to Błąd. Moje powody rzucania tylko błędu prawdopodobnie nie mają zastosowania. „

jeśli twój kod używa async/ await, nadal dobrą praktyką jest odrzucanie za pomocą Errorzamiast 400:

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

Wiem, że jest to stare pytanie, ale natknąłem się na wątek i wydaje się, że istnieje tutaj związek między błędami a odrzuceniem, który działa w wielu przypadkach (przynajmniej w wielu przypadkach) często powtarzanej porady, aby nie używać obsługi wyjątków do zajmować się przewidywanymi przypadkami. Przykład: jeśli metoda asynchroniczna próbuje uwierzytelnić użytkownika, a uwierzytelnienie nie powiedzie się, jest to odrzucenie (jeden z dwóch przewidywanych przypadków), a nie błąd (np. Jeśli interfejs API uwierzytelniania był niedostępny).

Aby upewnić się, że nie tylko dzielę włosy, przeprowadziłem test wydajności trzech różnych podejść, używając tego kodu:

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`);

Niektóre rzeczy, które tam są, są zawarte z powodu mojej niepewności co do interpretera Javascript (lubię schodzić tylko do jednej dziury królika na raz); na przykład, zawarłem doSomethingfunkcję i przypisałem jej zwrot, aby dummyValuemieć pewność, że bloki warunkowe nie zostaną zoptymalizowane.

Moje wyniki to:

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

Wiem, że istnieje wiele przypadków, w których polowanie na małe optymalizacje nie jest warte kłopotu, ale w systemach na większą skalę te rzeczy mogą mieć dużą kumulatywną różnicę, i jest to dość surowe porównanie.

SO… chociaż myślę, że podejście przyjęte w odpowiedzi jest słuszne w przypadkach, w których oczekujesz, że będziesz musiał poradzić sobie z nieprzewidywalnymi błędami w funkcji asynchronicznej, w przypadkach, gdy odrzucenie oznacza po prostu „musisz przejść do planu B (lub C lub D…) „Myślę, że preferuję odrzucenie przy użyciu niestandardowego obiektu odpowiedzi.