Try catch или then catch для rest api?

Question

[Артем Лукьянов]

Есть обработчик запроса api, где db.query() это запрос к PostgreSQL, который возвращает Promise с resolve в случае удачи, и reject в случае ошибки(например, если неправильный пароль к бд).
Сам обработчик запроса:

async getAll(req, res) {
    const query = `SELECT * FROM users`
    return db
      .query(query)
      .then(({ rows, rowCount }) => res.status(200).send({ rows, rowCount }))
      .catch(error => res.status(400).send({ error }))
    // try {
    //   const { rows, rowCount } = await db.query(query)
    //   return res.status(200).send({ rows, rowCount })
    // } catch (error) {
    //   return res.status(400).send(error)
    // }
  }

Соответственно вопрос, как лучше обрабатывать промис, через try catch или then catch ? Прочитал на stackoverflow что try catch лучше использовать для синхронных действий, а then catch для асинхронных? Так ли это?

Answer 1

[profesor08]

Используй try/catch, про колбеки можешь забыть. Раньше только так можно было отловить какие-то исключения во время выполнения, теперь в них нужды нет.

Код чище, понятнее.

async getAll(req, res) {
    try {
       const { rows, rowCount } = await db.query(query)
       return res.status(200).send({ rows, rowCount })
    } catch (error) {
       return res.status(400).send(error)
    }
  }

Comments

[xmoonlight]

Используй try/catch, про колбеки можешь забыть.

Ага, и про обратные цепочки событий - тоже. Вот она где чушь-то!

[Артем Лукьянов]

Ну насчёт чистоты - не знаю, ибо с then-catch код получается как минимум короче, если конечно в стрелочной функции не громаздить много кода.

[profesor08]

xmoonlight, и про них тоже, в них нет нужды, при использовании async/await.

Артем Лукьянов, ага, короче, ага, не громоздить.

var query = Posts.findOne({id: id});
var promise = query.exec();

promise.then(function (post) {
  var query1 = Comments.find({id: post.id});
  var promise1 = query1.exec();
  promise1.then(function(comments) {
    var query2 = Links.find({id: post.id});
    var promise2 = query2.exec();
    promise2.then(function(links) {
      res.json({post: post, comments: comment, links: links})
    })
  })
});

[Interface]

profesor08, Артем Лукьянов Ну тут справедливости ради код с .then() / .catch() неоправданно запутан.

Если принять во внимание, что post.id используется дважды.
А также допустить что id используемый тут Posts.findOne({id: id}) это тоже post.id, то код можно переписать так:

Promise.all([
    Posts.findOne({id}).exec(),
    Comments.find({id}).exec(),
    Links.find({id}).exec(),
])
    .then(([post, comments, links]) => {
        res.json({post, comments, links});
    });

Что вполне себе нормально читается. Более того, теперь запросы выполняются параллельно, не дожидаясь завершения предыдущего, что в общем случае лучше.
Код с async/await тут выглядел бы не сильно лучше:

const [post, comments, links] = await Promise.all([
    Posts.findOne({id}).exec(),
    Comments.find({id}).exec(),
    Links.find({id}).exec(),
]);
res.json({post, comments, links});

Ситуация меняется, если каждый последующий вызов зависит от предыдущего, а в конце нам интересны результаты каждого вызова. Это можно изобразить примерно так:

Posts.findOne({id}).exec()
    .then(post => {
        Users.findOne({id: post.authorId}).exec()
            .then(author => {
                Users.findOne({id: author.invitedBy})
                    .then(invitedByUser => {
                        res.json({post, author, invitedByUser});
                    });
            });
    });

Я не стал усложнять код дополнительными переменными и старым стандартом языка (кроме async/await конечно).

Тогда как код с async/await выглядит действительно проще:

const post = await Posts.findOne({id}).exec();
const author = await Users.findOne({id: post.authorId}).exec();
const invitedByUser = await Users.findOne({id: author.invitedBy}).exec();
res.json({post, author, invitedByUser});

Но при этом это не единственный способ как можно оформить код без async/await. Так в этом примере с каждым новым зависимым запросом растет вложенность кода. Этого можно избежать, если писать код как-то так:

Posts.findOne({id}).exec()
    .then(post => {
        return Users.findOne({id: post.authorId}).exec()
            .then(user => ({post, user}))
    })
    //...
    // произвольное количество дополнительных шагов без увеличения вложенности
    //...
    .then(data => {
        return Users.findOne({id: author.invitedBy})
            .then(invitedByUser => ({...data, invitedByUser}));
    })
    .then(data => res.json(data));

Это не делает его супер читаемым, но сдерживает вложенность на каком-то уровне.

При этом такой сложный код с .then()/.catch() получается именно в случае если одновременно:
- каждый запрос зависит от предыдущего
- нужно получить результаты промежуточных запросов в конце

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

Однако, если хотя бы одно условий не выполняется:
- если запросы независимы друг от друга, то можно (и нужно) использовать Promise.all (см. пример выше)
- если нас интересует только результат конечного промиса (invitedByUser), то можно переписать код так:

Posts.findOne({id}).exec()
    .then(post => Users.findOne({id: post.authorId}).exec())
    .then(author => Users.findOne({id: author.invitedBy}).exec())
    .then(invitedByUser => res.json(invitedByUser));

Что намного проще и сопоставимо по сложности с async/await.

---

Но в целом я с profesor08 согласен и советую использовать async/await как и многие другие современные возможности языка везде где это возможно и оправдано.

Answer 2

[xmoonlight]

Прочитал на stackoverflow что try catch лучше использовать для синхронных действий, а then catch для асинхронных? Так ли это?

Да.
Т.к. try-catch блокирует дальнейшее исполнение кода (если он без async/await обёртки) и ждёт завершения текущей секции.

Comments

[Interface]

try / catch же будет работать с async/await

[xmoonlight]

Interface, Вы путаете секции с потоками.

[Артем Лукьянов]

Спасибо! Но почему во многих гайдах пишут именно конструкцию try catch? Неопытность?

[xmoonlight]

Артем Лукьянов, скорее, привычка (и незнание конструкции then-catch): во всех языках программирования try-catch - как стандарт отлова ошибок.

[Артем Лукьянов]

xmoonlight, понятно, спасибо!)

[profesor08]

xmoonlight,

скорее, привычка (и незнание конструкции then-catch)

Чушь. На момент появления промисов, не было такой вещи как async/await, и обработка через колбеки приводила код в адовую штуку. Потом ввели и нужда в .catch/.then отпала.

[xmoonlight]

profesor08, однако, не всё так однозначно, если используют данную конструкцию по сей день.

[profesor08]

xmoonlight, чтоб не трансплитить код / нет времени переписывать ради фичи

[Interface]

xmoonlight, не очень понимаю причем тут потоки.

Т.к. try catch блокирует дальнейшее исполнение кода и ждёт завершения текущей секции.

это можно трактовать как: try{} catch(e){} блокирует основной поток js до тех пор пока промис не зарезолвится. Но это конечно не так.

function sleep(ms) {
    return new Promise(resolve => setTimeout(resolve, ms));
}

async function main() {
    console.log(1);
    try {
        console.log(2);
        await sleep(10);
    } catch(e) {

    }
    console.log(3);
}

console.log('outer: 1');
main();
console.log('outer: 2');

Ваш ответ звучит так как-будто 'outer: 2'. Не будет выведно до тех пор пока не звершится (не зарезолвится промис внутри) main. То есть как-будто try / catch превращает функцию в синхронную на манер синхронного XHR. Но это не так.

Результат будет

outer: 1
1
2
outer: 2
3

Что логично.

То есть код в примере выше эквивалентен:

async function main() {
    console.log(1);
    return sleep()
        .catch(() => {})
        .then(() => {
            console.log(3);        
        });
}

Если же вы имели в виду то что код после await'а (в рамках той же функции) не будет выполнен пока не промис переданный в await не будет разрешен - то это ожидаемо и работает так же как во втором примере. console.log(3) не будет выполнено до тех пор пока промис вернувшейся из sleep не будет разрешен.

Так что я согласен с profesor08 не вижу причин не использовать try/catch с async/await. По крайней мере в рамках этой дискуссии

[Interface]

xmoonlight,

однако, не всё так однозначно, если используют данную конструкцию по сей день.

Если вы про .then().catch() то ее использование может быть оправдано в случае если вам надо, например
- и сделать ассинхронный запрос (например) send(...)
- и выполнить синхронно код сразу после "отправки" запроса
- и отреагировать на его результат
function main() {
send()
.then(() => {
console.log('request finished');
});
console.log('request sent');
}
main();
Это может быть нужно, если, например, send(...) может бросить синхронное исключение, тогда вы не хотите выводить console.log('request sent');

Такая конструкция не может быть (насколько мне известно) преобразована в async/await.

В большинстве же случаев не вижу никаких проблем использовать async/await.

[xmoonlight]

Interface,

В большинстве же случаев не вижу никаких проблем использовать async/await.

А кто вообще начал разговор про async/await и, разве кто-то говорил, что будут какие-то проблемы при их использовании? Я не говорил вообще такого: Вы сами придумали.

[profesor08]

Interface,

Такая конструкция не может быть (насколько мне известно) преобразована в async/await.

Может, не пиши await перед вызовом, и все отработает.

[profesor08]

xmoonlight, зато написал окровенную чушь и ввел автора вопроса в заблуждение, теперь он будет в нее верить, если не прочтет комментарии.

[Interface]

xmoonlight, разговор про async/await начал автор вопроса Артем Лукьянов потому что в описании вопроса в закомментированной части как раз таки оно и используется. То есть вопрос изначально о том, что лучше .then().catch() или async/await + try/catch.

Я не говорил вообще такого: Вы сами придумали.

Я и не приписывал вам никогда таких слов :)

Я просто не понимаю вашего ответа, на самом деле.

try/catch ничего не "блокирует" сам по себе. await не дает исполнится следующим за ним инструкциям, пока не разрешиться промис, но при этом весь остальной код (например, обработчики событий) будут работать без проблем. Наличие или отсутствие try/catch на это не влияет. Поэтому я не говорил бы, что в данном контексте что-то "блокируется", потому что это вводит в заблуждение. Примером блокирующего запроса можно привести синхронный xhr (как я писал ранее) или, например, fs.readFileSync().

Возможно вам показалось, что альтернативой .then().catch() в коде автора был код такого плана:

try {
  const { rows, rowCount } = db.querySync(query) // положим querySync синхронная версия db.query
  return res.status(200).send({ rows, rowCount })
} catch (error) {
  return res.status(400).send(error)
}

Тогда мне понятна ваша аргументация против такого подхода.

[xmoonlight]

Interface, именно это я и имел ввиду. Я дополнил ответ уточнением.

[Interface]

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

То есть если нужно чтобы код такого плана:

function send() {
    console.log(1);
    return new Promise(resolve => setTimeout(resolve, 1));
}

function main() {
    send()
        .then(() => {
            console.log(3);
        });
    console.log(2);
    
}
main();

выводил в консоль 1 2 3, то не получится .then() заменить на await (не меняя код send).

Ну или, конечно, я что-то упускаю.

[Артем Лукьянов]

profesor08, прочитал, и ещё больше запутался ))

[profesor08]

Interface, async/await это замена, с их помощью можно сделать все, только проще.

function async main() {
  const p = await send();
  console.log(2);
  // делаем что-то с p
  console.log(3);
}

[Interface]

profesor08, моя конечная цель была конечно не выводить в консоль числа. Иначе можно было и

console.log(1);
console.log(2);
console.log(3);

обойтись :)

Я это к тому, что это не замена.

Приведу другой пример:

// просто какая-то ресурсоемкая синхронная функция
function heavyJob() {
    let i = 1e6;
    let s = '';
    while (i--) {
        s += Math.random().toString(36);
    }
    return s.length;
}

function makeRequest() {
    return new Promise(resolve => setTimeout(resolve, 1000));
}

function generateFingerprint() {
    const foo = heavyJob();
    return makeRequest(foo);
}

// ====

function profile(fn) {
    let started = Date.now();
    fn().then(() => { // Вот тут не обойтись без then
        console.log(`Async time: ${Date.now() - started}`);
    });
    console.log(`Sync time: ${Date.now() - started}`);
    started = Date.now();

}

profile(() => generateFingerprint());

я ожидаю от этого кода, что он выведет что-то вроде:

Sync time: 497
...
Async time: 1000

Подобный код может быть использован для мониторинга / анализа node.js сервера.

----

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

function callAsyncMethod(obj, methodName) {
    try {
        obj[methodName]()
            .catch(err => console.error(`replied with ${err}`));
    } catch(e) {
        console.error(e);
        process.exit(1);
    }
}

----

ну и еще один пример, это когда ассинхронный вызов находится внутри синхронной функции, которая что-то возвращает, например:

class Cart {

    // ...

    send(cart) {
        fetch(cart)
            .then(data => this.eventEmitter.emit('sent', data));
        return this; // это нужно вернуть синхронно не дожидаясь ответа
    }

    render() {
        // ...
    }

    // ...
}

// ...

const cart = new Cart();

cart.eventEmitter.on('sent', alert('cart was sent'));

cart
    .send()
    .render();

или, например, когда нужно вернуть некий requestId:

function send() {
    const promise = AJAXLibrary.someRequest()
        .then(data => JSON.parse(data)) // вот тут тоже .then()
        .catch(err => null);
    return [promise, AJAXLibrary.currentRequestId];
}

// ...

const [promise, requestId] = send();
console.log(`request <${requestId}> started`);
const data = await promise;

---

То есть по сути все примеры крутятся вокруг того, как вставить некоторый ассинхронный вызов внутрь синхронной функции.
Оставив ее синхронной.

P.s. да большинство кейсов можно решить примерно так

function syncFn() {
    console.log(1);
    (async () => {
        await fetch(...);
        console.log('resolved');
    })();
    console.log(2);
}

Но написать .then() будет явно проще и понятнее.

P.s.P.s. я ни в коем случае не призываю использовать .then() в случаях когда можно использовать async/await.
Наоборот, я считаю async/await одним из лучших нововведений языка.

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

[profesor08]

Interface, Обошелся без .then

async function asyncCall(fn, started) {
	const result = await fn();
	console.log(`Async time: ${Date.now() - started}`);
}

async function profile(fn) {
    let started = Date.now();
    asyncCall(fn, started);
    console.log(`Sync time: ${Date.now() - started}`);
    started = Date.now();
}

Обработал по разному синхронную и асинхронную операцию

async function callAsyncMethod(obj, methodName) {
    try {
        const method = obj[methodName];
        
        try {
        	await method();
        }
        catch(err) {
        	console.error(`replied with ${err}`)
        }
    } catch(err) {
        console.error(err);
        process.exit(1);
    }
}

И тут

class Cart {

		async fetchCart(cart) {
			const data = await fetch(cart);
      this.eventEmitter.emit('sent', data);
		}

    send(cart) {
        this.fetchCart(cart);
        return this;
    }

    render() {

    }
    
}

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

Нету таких мест. async/await это абсолютная замена then/catch, покрывает любые кейсы и предоставляет больше возможностей.