Т.Е. Either, как альтернатива выбрасыванию исключений — это по вашему

ненормальная практика? И если кто-то использует throw для Control Flow Interruption, там где без этого можно/нужно обойтись, как это может меня побудить следовать этому, пусть даже это будут те, кто создают Flutter?

Кажется это вы ничего в этом споре не поняли. Прочитайте это сообщение еще раз: https://t.me/rudart/753988

И что это меняет? Тем более я там не вижу какого-то кода. Ему советуют сделать https://t.me/rudart/753983 т.е. либо вернуть результат либо try-catch НЕ результат, а используя Either можно/нужно этого избежать. Я об этом.

Ладно, у меня уже нет времени и желания с вам спорить...

Т.е. если вам придется возвращать либо результат, либо НЕ результат вы выберете конструкцию с throw и try-catch, а не Either? Ну, или какие-то данные, где может быть либо один тип, либо другой.

> У меня предполагается, что try-catch сработает внутри блока initialization и вернется Left(AppError(..)) Где вы тут увидили либо результат, либо НЕ результат? Судя по сообщению есть какой-то метод initialization (скорее всего асинк), внутри которого есть try-catch значить блок кода который обернут в try-catch может вернуть ошибку (уже не подходит either/result). Более того, как мне кажется, там не один тип ошибки может вернуться (просто автор кода об это не думал еще). Так еще взгляните на это Left(AppError(..)), автор кода явно хочет вернуть и обработать ошибку дальше по коду иначе там бы не было бы в названии Error. Я даже предполагаю откуда автор кода подчеркнул идею с either, если интересно ввидите в поиске гитхаба: flutter clean architecture (первый репозиторий)

то чего хотел автор сложно понять, но сопоставив его желание использовать Either и советы ему вместо Either использовать throw и try-catch я решил, что это плохой совет. Тем более, далее дискуссия переросла в несколько спорных утверждений: функциональщик, Доказать что то нам - не докажете, как бы вы не пытались, try catch - это базовое решение от самого языка — можно подумать что Either написан на каком-то другом языке и использует не базовые синтаксис/конструкции. Да и ваше заявление вместо того чтобы тянуть знания из других ЯП и натягивать их на dart довольно спорное, методология программирования она общая: парадигмы, принципы, паттерны. Те, кто не используют И функциональный подход (на самом деле используют, просто не осознают этого) просто ограничивают себя в инструментах. А Either — это уже паттерн.

Как мне кажется (просто я конечно же могу ошибаться), мне нужно сделать функцию, которая в случае успешного завершения ничего не возвращает, а в случае проблемы, возвращает код проблемы. На это меня натолкнула basic usage из pub.dev either_dart. Ошибки разный могут быть и все типы в enum (как в том же примере) В ходе обсуждения я понял, что что-то идет не так и either не подходит. А что за рипо, из которого я почерпнул идею? Первый в списке https://github.com/ResoCoder/flutter-tdd-clean-architecture-course. Он?

Удачи перетянуть методологию программирования с dart на go 1 и попытаться там перехватывать ошибки через try catch)

go тут причем?

как пример перехода на следующий ЯП

Про репо я только "предполагал") Как мне кажется вам достаточно возвращать enum и игнорировать если он none/empty. И не нужно будет тянуть either_dart)

Да я уже давно понял, что either (или что там еще может быть) тут совершенно лишний. Всем спасибо! Тему можно считать закрытой и не стоящей холиваров😂

Добро победило!

тут речь вообще не про ошибки, а про Control Flow Interruption я уже ссылался что это goto ну и много всего остального, чего нет при использовании Either. Я не понимаю, чем Either плох, вы видите что-то плохое в его использовании? Даже документация Bloc изобилует примерами CFI. В Bloс там много интересного, например инстанс который прикидывается методом — вот где галимая 😂 функциональщина, злая и бессмысленная — но Dart же позволяет!