Comments 8
статью надо было назвать "как грамотно запудрить мозги рассуждая о последовательности из пяти операций условного присваивания"
Похоже на анекдот когда шевелят пальцами а потом спрашивают где какой, только тут после шевеления говорят: Видишь! Все пальцы на месте остались! Это все потому что у нас:
ФП, монады, railway-oriented programming , ООП, ТДД, ... ИТД ИТП
Круто!
Не в обиду, но тут такой краткой статьей не обойдешься. Куда было бы интереснее если бы была серия статей, и в них было бы что-то новенькое. А так по сути это набор общеизветных правил, которые еще и скомканы.
Ничего не понятно, но очень интересно)
Как и в вашем недавнем докладе на Jpoint - заголовок интересный, но непосредственно из содержания что-то вынести по сути нельзя. Как-то по верхам слишком. Допустим, про уход от исключений, монады было бы интересно чуть подробнее почитать.
А также мы отказались от исключений.
Все проблемы с исключениями исключительно :) от непонимания их отличия от ошибок и неумения с ними работать. Ошибка это штатная, предусмотренная ситуация. А исключение это потому и исключение, что это ситуация "исключительная" в которой ничего разумного нельзя сделать кроме как прервать текущую операцию и вернуться к самому началу стека вызовов. Как простой пример, проверка входных данных - если это часть внешнего API и туда могут попадать любые непроверенные данные, (например от пользователя), то некорректные данные это именно "ошибка". Если же это какой-то внутренний компонент и его контракт требует передавать ему только уже проверенные, корректные данные, то некорректные данные это уже "исключение". И исключения вообще нигде не надо перехватывать. Их надо либо обрабатывать глобально в одном месте на самом "верху" приложения, либо (как правило) это вообще уже и так встроенно в сам используемый фреймворк. А если в коде миллион повсюду раскиданных блоков try-catch, то тогда и возникает лапша с "где-то далеко по стеку".
CI, кодстайл и TDD: обзор практик для повышения качества кода