Обработка catch при async await?

Question

[thehighhomie]

привет ребят)) помогите понять пожалуйста описывание catch при async await, дичь прост полная постоянно catch писать там где не надо..

вот смотрите, у меня есть файл auth.service.js и экшены store/modules/auth/actions.js

так вот, в auth.service.js я пишу функцию логина:

async login ({ email, password }) {
try {
const res = await ApiService.post('/users/login', { email, password })

JwtService.saveToken(res.data.token)
JwtService.saveRefreshToken(res.data.refreshToken)

return res.data
} catch (error) {
return error // тут я просто возвращаю ошибку, не знаю правильно ли...
}
}

а вот store/modules/auth/actions.js:

async [LOGIN] ({ commit }, { email, password }) {
try {
const res = await AuthService.login({ email, password })
commit(`${[SET_AUTH]}`, res)
router.push('/users')
} catch (error) {
commit(`${[SET_ERROR]}`, error) // тут я уже просто сохраняю ошибку...
}
}

дело в том, что я хз как поступить с ошибками в catch, либо возвращать их, либо в каждом файле дублировать код и как-то обрабатывать ошибку ВЕЗДЕ, либо еще что.... но по факту она как я понял нужна только в store/modules/auth/actions.js, чтобы я сохранил ее.

ну в промисах можно вообще catch не писать там где не надо...

Answer 1

[villager123]

Сделай проверку - если режим разработки или отладки - показывать ошибки, иначе - нет.

Answer 2

[Антон Швец]

ну так не перехватывайте ошибки там где не надо.
Метод login не должен возвращать ошибку.
Его задача в чем? - обеспечить логин. Это действие никак не связано с возвратом каких-либо значений. Максимум что можно - ловить ошибки, разбирать их и бросать свои, более конкретные. Но опять таки, это не задача логина. В нем не должно быть блока try catch вообще

Не стоит вешать лишнюю логику в методы, которые должны делать одно что-нибудь простое. Следуйте правилу SPR.

Answer 3

[Дима Паутов]

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

За свой опыт придумал 3 реализации:
1) Создать миксин с методом показа ошибок
2) В самом обработчике ajax сделать обработку ошибок, если у тебя axios то вообще фигня делов, но, т.к. это плагин, то внутри плагина нет возможности достучаться до компонентов и каким-то образом вывести какое нибудь окошко, подойдёт лишь для console.log и т.п. обработок ошибок.
3) Основан на примере 2. В самом обработчике ajax сделать обработку ошибок так, что бы при ошибке в запросе, ошибка записывалась в store, создать компонент, в котором будет реализовано отображение ошибок из store, чистить store, после показа всех ошибок, например, по таймеру.

Мой личный опыт: я юзаю пока что 1й вариант, в миксине я юзаю вызов из прототипа метод с показом кастомных алертов. Минус подхода в том, что нужно импортировать миксин и прописывать в catch метод вызова обработчика ошибок, передовая в него error из catch/

Думал думал и придумал вариант 3, но ещё не реализовывал.

Answer 4

[Ihor Bratukh]

Раньше тоже замачал такую проблему на асинхронных метода. Если раньше был callback hell, то сейчас try/catch hell)
В последнее время практикую один способ, который всегда резолвится, но возвращяет массив где первый элемент ошибка либо undefined а второй результат или undefined. В итоге выходит что на уровнях выше не нужно плодить try/catch. Пока подводных камней не увидел, главное взять себе за привычку всегда отрабатывать ошибки.

const [myError, myResult] = await a();
if (myError) { ... } else { ... }

async function a() {
    try {
        const r = await c();
        return [undefined, r];
    } catch (error) {
        return [error, undefined];
    }
}