Как отказаться от асинхронного / ожидающего синтаксиса?

Как я могу отклонить обещание, возвращаемое функцией async / await?

например, первоначально

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

Перевести на async / await

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

Итак, как я мог должным образом отклонить это обещание в этом случае?

Лучше всего , чтобы throwна Errorупаковку значения, что приводит к отклоненному обещанию с Errorобертыванием значения:

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

Вы также можете просто throwуказать значение, но тогда нет информации о трассировке стека:

} catch (error) {
    throw 400;
}

Либо верните отклоненное обещание с Errorпереносом значения, но это не идиоматично:

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

(Или просто return Promise.reject(400);, но опять же, тогда нет никакой контекстной информации.)

(В вашем случае, поскольку вы используете, TypeScriptи fooзначение retrn равно Promise<A>, вы бы использовали return Promise.reject<A>(400 /*or error*/);)

В async/ awaitситуации это последнее, вероятно, немного семантическое несоответствие, но оно работает.

Если вы бросаться Error, что играет хорошо с чем - нибудь , потребляющим своим fooрезультатом «с с awaitсинтаксисом:

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

Вероятно, следует также упомянуть, что вы можете просто связать catch()функцию после вызова асинхронной операции, потому что внутри все еще возвращается обещание.

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

Таким образом, вы можете избежать try/catchсинтаксиса, если он вам не нравится.

Вы можете создать функцию- оболочку, которая принимает обещание и возвращает массив с данными, если ошибки нет, и ошибку, если произошла ошибка.

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

Используйте это так в ES7 и в асинхронной функции:

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
}

Лучшим способом написания асинхронной функции было бы возвращение ожидающего обещания с самого начала и последующая обработка как отклонений, так и разрешений в обратном вызове обещания, а не просто выдача отклоненного обещания по ошибке. Пример:

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

Затем вы просто цепляете методы на возвращенном обещании:

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

bar()

Источник - этот урок:

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

У меня есть предложение правильно обрабатывать отклонения в новом подходе, не имея нескольких блоков 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;
}

Откуда должна быть импортирована функция to.ts :

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

Кредиты отправляются Диме Гроссману по следующей ссылке .

Это не ответ на вопрос @TJ Краудера. Просто комментарий, отвечающий на комментарий «И на самом деле, если исключение будет преобразовано в отклонение, я не уверен, действительно ли я обеспокоен, если это ошибка. Мои причины для выдачи только ошибки, вероятно, не применимы. "

если ваш код использует async/ await, то все равно рекомендуется отклонять Errorвместо 400:

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

Я знаю, что это старый вопрос, но я просто наткнулся на поток, и здесь, похоже, существует связь между ошибками и отклонением, что противоречит (во многих случаях, по крайней мере) часто повторяемого совета не использовать обработку исключений для иметь дело с ожидаемыми случаями. Чтобы проиллюстрировать: если асинхронный метод пытается аутентифицировать пользователя и аутентификация не удалась, это отклонение (один из двух ожидаемых случаев), а не ошибка (например, если API аутентификации был недоступен).

Чтобы убедиться, что я не просто раскалывал волосы, я провел тест производительности трех разных подходов к этому, используя этот код:

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

Некоторые вещи, которые там есть, включены из-за моей неуверенности в отношении интерпретатора Javascript (мне нравится проходить только одну кроличью нору за раз); например, я включил doSomethingфункцию и назначил ее возврат, dummyValueчтобы гарантировать, что условные блоки не будут оптимизированы.

Мои результаты были:

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

Я знаю, что есть много случаев, когда не стоит искать небольшие оптимизации, но в более крупных системах эти вещи могут иметь большое совокупное значение, и это довольно резкое сравнение.

ТАК ... хотя я думаю, что подход принятого ответа является обоснованным в тех случаях, когда вы ожидаете обработки непредсказуемых ошибок в рамках асинхронной функции, в тех случаях, когда отклонение просто означает «вам придется пойти с планом B (или C или D…) «Я думаю, что я предпочел бы отказаться от использования пользовательского объекта ответа.