Подскажите, как тут правильней поступить?

Не использовать void в Either. Или взять Option или Nullable aka T?

Смотря что надо, судя по всему вы хотите чтобы функция возвращала класс AppError при ошибке и какую-то функцию если нет ошибки? Если нет и вы просто хотите ловить ошибку на Left, то на Right передайте пустую анонимную функцию (){} - подойдет под сигнатуру void

null

Да, вот на null даже линтер не ругается 👍🏻 Хотя все это выглядит немного странновато

не использовать either

Option? А как с ним сделать? чет я не понял

А для чего вы там Either используете, чтобы что?

ошибки отлавливать лишь

и, что вам Either даёт?

Option<AppError> initAll(){.... return Some(AppError(...))}

Обычно используют для отделения например блока от логики try - catch. В Either левый аргумент делают Failure класс от которого затем наследуется ServerFailure или FireStoreFaulure и у каждого класса свой парсинг Exceptionа По большей степени это чисто архитектурное решение для разделения слоев. Но в чем то и доп куча кода

Это было придумано, чтоб не возвращать null в случае ошибки

В чем проблема throw сделать?

И дальше что? throw это для программиста сообщение, а юзеру программы ты что покажешь? или молча упадешь?

try catch???

А дальше? Думай дальше...

У меня предполагается, что try-catch сработает внутри блока initialization и вернется Left(AppError(..)) А если ошибок не будет, то вернется void - ничего не вернется

void - плохо, очень плохо.

Ну если метод выполнится, то ниче не вернет, если что то пойдет не так - кинет исключение. А ты его словишь сверх через блок try catch и делай с ним че хочешь. Either по сути никакую проблему не решает, так что я лично к этому субъективно отношусь

нет, Either это более правильный вариант, чем try catch. Через try catch — дерьмовый вариант, не нужно так делать.

Кек, а как вы собираетесь первоначально ловить ошибку и передавать ее в either/option/result без try catch?) А что мешает вам и дальше использовать try catch и дальше, если вы его будете в любом случае использовать?)

Tсли вы используете библиотеку, либо то, что может генерить исключения, будете ловить исключения через try-catch — у вас просто не будет другого выхода. В отличие от Java, все исключения в Dart являются непроверяемыми исключениями. Методы не объявляют, какие исключения они могут выбросить, и от разработчика не требуется перехватывать исключения. Если исключение не поймано, то изолят, вызвавший исключение, приостанавливается, и, как правило, завершается работа приложения (красный экран смерти 😃). Уже этого одного было бы достаточно, чтобы не использовать исключения для прерывания потока управления в приложении, что нарушает ожидаемый ход выполнения (Control Flow Interruption). Не надо множить возможность возникновения ошибок их и так будет предостаточно. Я не понимаю зачем это делать преднамерянно. Ладно если разработчик опытный, ну, про дурака уже как-то писал.

Накину дальше, а как вы при использовании either/result собираетесь проверять какая и откуда у вас ошибка? А где stack trace?

вы наверное не внимательно читали, тут про преднамерянный throw, который используют как Control Flow Interruption

Я все правильно прочитал и понял. И тот подход с throw это нормальная практика. Вы для начала посмотрите исходники dart sdk и flutter, и ознокомтесь как в dart работают с Control Flow Interruption, вместо того чтобы тянуть знания из других ЯП и натягивать их на dart...