Доклад хороший, но нужно снять розовые очки Вижу очевидную проблему - перегруженность: Представим, что нам нужно поочереди обработать 3 запроса, где 1 зависит от 2, а 2й от 3го (их может быть больше) Что мы получим? +пару десятков строк проверок, что результат 1 не ошибка, что результат 2 не ошибка и результат 3 не ошибка. Для избегания этого и придумали try catch, разве нет? Решение проблемы разделения ошибок и исключений простейшая - завести класс внутренних ошибок и метод, который перепрокидывает ошибку, если это не внутренняя ошибка. Проблема с типизацией отпадает если задать вопрос "Зачем она нужна?". Тип данных нужен для обработки данных. Если обрабатываешь данные, то нужно знать какая это конкретно ошибка, иначе получится error: Error1 | Error2 | Error3 и всё еще нужен будет instanceof. Если это любая ошибка, то типа базового типа ошибки будет достаточно. Логирование - сделай функцию logAndThrow(e) или tryOrLog(() => {throw})
Монады позволяют как раз таки сначала полностью обработать позитивный flow. Далее отдельно обрабатывать ошибки. Если позитивный флоу не выполнится, сразу перейдем к ошибкам. Я к сожалению не могу ссылку на playground прикрепить потому что ссылки обрезаются. Каким образом вам try catch поможет избежать проверок на ошибку? В случае если не получился первый запрос, сделать throw ? Ну у вас будет пару десятков строк проверок. Если не выполнился первый запрос, выброси ошибку, иначе идем дальше. Если не выполнился второй запрос, выброси ошибку, иначе идем дальше. Только вот в catch вам придет unknown и вы понятия не имеет что вам нужно обработать
@@dzhabulyaвообще это сильно от языка зависит , например в c# в catch прилетит типизированная ошибка и там даже "ручная" проверка типа не потребуется т.к для каждого типа исключения будет свой блок обработки , да и еще с упорядоченным вызовом по наследственной линии , плюс ни с кем не нужно договариваться и что-то согласовывать , ибо спецификация языка говорит как нужно. В общем , в случае с конкретным языком , где есть грамотные исключения и хорошо спроектированный функционал их обработки , весь этот огород с монадой кажется оверхедом ненужным.
Это один из самых крутых и важных докладов, которые я когда либо видел.
Ссылки на упомянутые доклады:
1. ruclips.net/video/bJ3glfA-jqo/видео.html
2. ruclips.net/video/9s_4wpzENhg/видео.html
^_^
Золотые времена и Кот еще не дев-психолог 😁
Круто!
Доклад хороший, но нужно снять розовые очки
Вижу очевидную проблему - перегруженность:
Представим, что нам нужно поочереди обработать 3 запроса, где 1 зависит от 2, а 2й от 3го (их может быть больше)
Что мы получим? +пару десятков строк проверок, что результат 1 не ошибка, что результат 2 не ошибка и результат 3 не ошибка. Для избегания этого и придумали try catch, разве нет?
Решение проблемы разделения ошибок и исключений простейшая - завести класс внутренних ошибок и метод, который перепрокидывает ошибку, если это не внутренняя ошибка.
Проблема с типизацией отпадает если задать вопрос "Зачем она нужна?". Тип данных нужен для обработки данных. Если обрабатываешь данные, то нужно знать какая это конкретно ошибка, иначе получится error: Error1 | Error2 | Error3 и всё еще нужен будет instanceof. Если это любая ошибка, то типа базового типа ошибки будет достаточно.
Логирование - сделай функцию logAndThrow(e) или tryOrLog(() => {throw})
Монады позволяют как раз таки сначала полностью обработать позитивный flow. Далее отдельно обрабатывать ошибки. Если позитивный флоу не выполнится, сразу перейдем к ошибкам. Я к сожалению не могу ссылку на playground прикрепить потому что ссылки обрезаются.
Каким образом вам try catch поможет избежать проверок на ошибку? В случае если не получился первый запрос, сделать throw ?
Ну у вас будет пару десятков строк проверок. Если не выполнился первый запрос, выброси ошибку, иначе идем дальше. Если не выполнился второй запрос, выброси ошибку, иначе идем дальше.
Только вот в catch вам придет unknown и вы понятия не имеет что вам нужно обработать
@@dzhabulyaвообще это сильно от языка зависит , например в c# в catch прилетит типизированная ошибка и там даже "ручная" проверка типа не потребуется т.к для каждого типа исключения будет свой блок обработки , да и еще с упорядоченным вызовом по наследственной линии , плюс ни с кем не нужно договариваться и что-то согласовывать , ибо спецификация языка говорит как нужно.
В общем , в случае с конкретным языком , где есть грамотные исключения и хорошо спроектированный функционал их обработки , весь этот огород с монадой кажется оверхедом ненужным.
@@sau9703 Так доклад был про typescript. Причем тут c# )