Size: a a a

NestJS — русскоязычное сообщество

2020 March 06

PS

Poluektov Sergey in NestJS — русскоязычное сообщество
На мой взгляд, важная проблема исключений не в том, что их семантически неверно использовать для обработки ошибок. А скорее в том, что исключения не типизируются. По сигнатуре функции/метода ты не поймёшь, выбрасывает она исключения или нет, нужно тебе обрабатывать ошибки или нет. С явным возвратом ошибки, например, с Either ты не получишь uncaught exception
источник

DB

Dilame Bowzee in NestJS — русскоязычное сообщество
Andrey Melikhov
Исключения не должны пересекать границы слоёв и исключения не должны управлять логикой приложения. Они должны оставаться крайней мерой
> не должны пересекать границы слоёв
Прости, вот тут тоже не совсем понял. Разве не для этого они предназначены? Наоборот, выкидывать исключения для того, что бы поймать его в пределах одного слоя - вот что есть goto.
источник

AM

Andrey Melikhov in NestJS — русскоязычное сообщество
Poluektov Sergey
На мой взгляд, важная проблема исключений не в том, что их семантически неверно использовать для обработки ошибок. А скорее в том, что исключения не типизируются. По сигнатуре функции/метода ты не поймёшь, выбрасывает она исключения или нет, нужно тебе обрабатывать ошибки или нет. С явным возвратом ошибки, например, с Either ты не получишь uncaught exception
да это тоже огромная проблема исключений
источник

DB

Dilame Bowzee in NestJS — русскоязычное сообщество
Poluektov Sergey
На мой взгляд, важная проблема исключений не в том, что их семантически неверно использовать для обработки ошибок. А скорее в том, что исключения не типизируются. По сигнатуре функции/метода ты не поймёшь, выбрасывает она исключения или нет, нужно тебе обрабатывать ошибки или нет. С явным возвратом ошибки, например, с Either ты не получишь uncaught exception
Обеими рукам плюсую)
источник

DB

Dilame Bowzee in NestJS — русскоязычное сообщество
Но я видел issue в репе TS, вроде как думают как это сделать.
источник

AM

Andrey Melikhov in NestJS — русскоязычное сообщество
Dilame Bowzee
> не должны пересекать границы слоёв
Прости, вот тут тоже не совсем понял. Разве не для этого они предназначены? Наоборот, выкидывать исключения для того, что бы поймать его в пределах одного слоя - вот что есть goto.
по хорошему если у тебя исключение летит через все слои то нет никакой гарантии что его кто-то поймает, кроме общего обработчика исключений. Т.е. для упавшего приложения это нормально да.
источник

DB

Dilame Bowzee in NestJS — русскоязычное сообщество
Andrey Melikhov
да, гарды это application layer и исключение тут его не покинет. Претензия в том, что это goto-стиль — ты организуешь логику нормального поведения приложения через выбрасывание и поимку исключений. Это грязно.
Но ведь Application Layer не плоский? Он тоже делится на множество под-лейеров? Например, гарды - Access-Control layer
источник

AM

Andrey Melikhov in NestJS — русскоязычное сообщество
Dilame Bowzee
Но ведь Application Layer не плоский? Он тоже делится на множество под-лейеров? Например, гарды - Access-Control layer
Я не доходил до такой упоротости по слоям ) мне хватает 3-х
источник

AM

Andrey Melikhov in NestJS — русскоязычное сообщество
Poluektov Sergey
На мой взгляд, важная проблема исключений не в том, что их семантически неверно использовать для обработки ошибок. А скорее в том, что исключения не типизируются. По сигнатуре функции/метода ты не поймёшь, выбрасывает она исключения или нет, нужно тебе обрабатывать ошибки или нет. С явным возвратом ошибки, например, с Either ты не получишь uncaught exception
вот кстати в java с этим проблем нет, там исключения видны и требуют обработки. Хоть в чём-то легче
источник

IL

Ihor Levchenko in NestJS — русскоязычное сообщество
Кстати да.
Странно что в шарпе нет подобного
источник

PS

Poluektov Sergey in NestJS — русскоязычное сообщество
Andrey Melikhov
вот кстати в java с этим проблем нет, там исключения видны и требуют обработки. Хоть в чём-то легче
Ну так, а где-то (читай чистые ФП языки) вообще нет исключений :)
источник

AM

Andrey Melikhov in NestJS — русскоязычное сообщество
Poluektov Sergey
Ну так, а где-то (читай чистые ФП языки) вообще нет исключений :)
логично, это же грязный сайд-эффект )
источник

PS

Poluektov Sergey in NestJS — русскоязычное сообщество
Ну вот так и с исключениями. Можно упороться по чистоте и иммутабельности и пилить все обмазываясь монадами и аппликативными функторами (см Haskell)
А можно грамотно это применять не переусложняя там, где не надо и мутируя под контролем (см. OCaml)
источник

DB

Dilame Bowzee in NestJS — русскоязычное сообщество
А, ну я вот эту мысль как раз и хотел донести - нет таких ситуаций, когда нельзя заменить исключение чем-то другим.
Если ты дошёл до того, что руками его выкидываешь, то ты можешь его и не выкидывать, а чем-то другим заменить.
Прикол только в том, что мы в JS, и он очень не идеален.
Я, кстати, после подкаста @amel_true пошёл искать себе монаду Either для TS. Нашёл, но не понял, как её внедрить в существующую экосистему. А ещё с удивлением обнаружил, что называющий себя функциональным RxJS такой не предоставляет, зато у него есть операторы throwError и catchError.

https://gcanti.github.io/fp-ts/modules/Either.ts.html
источник

PS

Poluektov Sergey in NestJS — русскоязычное сообщество
Dilame Bowzee
А, ну я вот эту мысль как раз и хотел донести - нет таких ситуаций, когда нельзя заменить исключение чем-то другим.
Если ты дошёл до того, что руками его выкидываешь, то ты можешь его и не выкидывать, а чем-то другим заменить.
Прикол только в том, что мы в JS, и он очень не идеален.
Я, кстати, после подкаста @amel_true пошёл искать себе монаду Either для TS. Нашёл, но не понял, как её внедрить в существующую экосистему. А ещё с удивлением обнаружил, что называющий себя функциональным RxJS такой не предоставляет, зато у него есть операторы throwError и catchError.

https://gcanti.github.io/fp-ts/modules/Either.ts.html
А в чем сложность с ней возникла? Я тут у себя в прототипе пользуюсь и норм
источник

AM

Andrey Melikhov in NestJS — русскоязычное сообщество
Dilame Bowzee
А, ну я вот эту мысль как раз и хотел донести - нет таких ситуаций, когда нельзя заменить исключение чем-то другим.
Если ты дошёл до того, что руками его выкидываешь, то ты можешь его и не выкидывать, а чем-то другим заменить.
Прикол только в том, что мы в JS, и он очень не идеален.
Я, кстати, после подкаста @amel_true пошёл искать себе монаду Either для TS. Нашёл, но не понял, как её внедрить в существующую экосистему. А ещё с удивлением обнаружил, что называющий себя функциональным RxJS такой не предоставляет, зато у него есть операторы throwError и catchError.

https://gcanti.github.io/fp-ts/modules/Either.ts.html
забей на монаду, задумайся просто над резалт-контейнером. ща хорошу статью скину
источник

AM

Andrey Melikhov in NestJS — русскоязычное сообщество
источник

DB

Dilame Bowzee in NestJS — русскоязычное сообщество
Poluektov Sergey
А в чем сложность с ней возникла? Я тут у себя в прототипе пользуюсь и норм
Ты прямо вот эту используешь, что я скинул?
Я просто очень активный юзер RxJS, и если совместить её с fp-ts получается какой-то франкенштейн.
Да и просто тот факт, то фреймворки не поддерживают это, даёт о себе знат
источник

AM

Andrey Melikhov in NestJS — русскоязычное сообщество
Вообще у него весь блог — моё почтение. это Developer Advocate в Apollo
источник

PS

Poluektov Sergey in NestJS — русскоязычное сообщество
Dilame Bowzee
Ты прямо вот эту используешь, что я скинул?
Я просто очень активный юзер RxJS, и если совместить её с fp-ts получается какой-то франкенштейн.
Да и просто тот факт, то фреймворки не поддерживают это, даёт о себе знат
Да прямо эту. Но я без RxJS
источник