V
я ж вам скинул выше статью от джейка арчибальда, это авторитетный чел)
Size: a a a
2019 November 15
Ð
100% отработает, не переживай, и даже finally отработает
R
Нормальный подход к программированию
Точно не знаю, но где-то слышал
Точно не знаю, но где-то слышал
искать нужно, мне лень
G
А че там, просто идёшь в мфц, пишешь заявление и ждёшь
Лезешь без очереди, дергает за плечо бабушка, размахивается клюкой и
process.exit()Ð
finally с авейтами это вообще классная штука, агалог defer в го.
A
Лезешь без очереди, дергает за плечо бабушка, размахивается клюкой и
process.exit()повезло что ты из браузера бабушку запустил
R
Ð
100% отработает, не переживай, и даже finally отработает
а ьыло когда не отрабатывал finally?
Ð
а ьыло когда не отрабатывал finally?
было, когда ты использовал колбеки )
R
Ð
было, когда ты использовал колбеки )
а так можно было? =)))
Ð
скажем так, до авейтов смысла в них было мало
АП
искать нужно, мне лень
Искать понимание того, как работают промисы и async/await?
Не парься
Не парься
AK
chat driven development во всей красе. дока - не оислена, гугл - не осилен.
A
точно не помню, но если юзать return в trycatch, то catch не отработает
если не юзать return и await в async функции то таки да - catch в try catch не отработает
A
только в этом случае
Ð
если не юзать return и await в async функции то таки да - catch в try catch не отработает
отработает, если ошибку плюнет сам билдер, а не запрос
A
Ð
отработает, если ошибку плюнет сам билдер, а не запрос
разумеется, имелось ввиду что в кэтч блок не попадет реджект промиса
Ð
ну вот как раз чтобы не было такого неявного поведения, лучше писать всегда
Ð
а проигрыш пару тиков на трайкетче - ерунда, когда ошибок нет он совершенно не тормозит, это спички.
A
интересный факт - в PEP (это такой набор рекомендаций для пайтона) есть заметка о том что порой лучше предпочесть один трайкейтч чем пачку ифов - так быстрее работает
Ð
в ноде тормозит new Error сильно, долго дергается стектрейс