> Как следствие возможно делать простые цепочки действий с минимальным количеством кода которые просто превращают один саксес в следующий пока не пройдут все итерации. Как и в случае с throw, но только кода не минимальное кол-во, а нулевое. :) > А если случается ошибка - она просто проходит дальше по цепочке резалтов пока не дойдет до точки вывода ошибки в интерфейс. Как и в случае с throw. :) С минимальным кол-вом кода, которое требуется только в месте выхода ошибки в интерфейс, а на нижележащих уровнях он не требуется. Не пойму твоей одержимости резалтами. По большому счету, между резалтами и throwing принципиальной разницы нет, вся разница, что есть — она в деталях. Но в целом throwing более гладко и с меньшим кол-вом усилий реализуется. Ошибка может подниматься из глубин иерархии на самый верх к месту ее обработки с нулевым кол-вом доп. кода, неявно. Потому что добавить "throws" к сигнатуре функции — это действительно нулевое усилие. Ну ладно, не ноль, а 0.000000000001 ;)
можешь показать тот же код что я написал там на throw?)
А причем здесь код, который ты написал? Я сравниваю каноническое использование того и другого. Ваши вчерашние ночные упражнения меня вообще не торкнули, я впервые за много месяцев позволил себе пролистать все новые сообщения чата не читая. :) Ты просто за резалты уже не в первый раз агитируешь (поливая throws при этом), а мне не очень понятно, зачем — эту бы энергию да в мирное русло, потому что отличий там действительно совсем немного. Метод/функция, возвращающая кортеж (T, Error) делает это явно. Метод/функция, возвращающая Result<T, Error> делает это тоже явно, но результат — это одно значение, а не кортеж, т.е. добавлен "контейнер" и унифицированный API работы с этим контейнером (.success/.failure) Метод/функция throws, возвращающая явно T и неявно Error — это дальнейшее абстрагирование, только и всего. Error вообще никак явно не анализируется в возвращаемом значении, если это не требуется на текущей ступени иерархии, а прокидывается выше неявно. Если надо обработать — do/catch. Ну соглашусь, это несколько более громоздкая конструкция, нежели switch .success/.falure, ну да и хрен бы с ней, пусть будет компенсация за упрощение и уменьшение кол-ва кода во всех остальных местах. Непринципиально. Повторюсь — принципиальных различий между всеми тремя способами нет. Во всех трех случаях назад возвращается 2 значения (результат выполнения либо ошибка). В текущем iOS-приложении использую в основном резалты (главным образом, в сетевом стеке), в вапоре всегда использую throws (вапор навязывает этот стиль). Сравнивая эти 2 подхода могу сказать, что если на промежуточном уровне иерархии мне надо выполнить какие-то действия с результатом, то с throws я просто их выполняю и всё. С резалтами же значение приходится разбирать на .success/.failure и прокидывать выше уже по-отдельности. Суммарно с throws кода меньше, простоты больше, прокидывание ошибок происходит неявно "за сценой", ты на нее внимания не обращаешь. В любом случае, эти 2 подхода не стоят и десятой части усилий на агитацию за любой из них, что ты уже потратил. :) Лично мне нравятся оба примерно в равной степени.
» Ну соглашусь, это несколько более громоздкая конструкция, нежели switch .success/.falure, ^^ в работе не использую даже switch для резалтов) Ну то есть где-то в загашниках в екстеншнах они есть, но на практике я себе еще упростил синтаксис работы с резалтами)
Обсуждают сегодня