исключениями, пользователь функции g() может и не знать, прилетит ли ему исключение, а если да – то какое и откуда, из func1(), func2()?
По сути, автор функции g() может просто взять и забить переложить ответственность за обработку ошибок вызываемых им функций на пользователя функции g(), по сути, оставляя прямое взаимодействие между пользователем функции и частью внутренней имплементации – func1(), func2(). Это не очень красиво, у нас протекла абстракция в случае, если требуется хоть сколько-нибудь нетривиальная обработка ошибки.
В случае же с монадами... Ну, автор функции g(), в идеале, явно укажет тип возвращаемого значения. А ещё ему придется позаботиться, чтобы в случае ошибок, возвращался один и тот же тип ошибки, ведь func1() и func2() могут вернуть разные монады для обработки разных типов ошибок. В любом случае, у пользователя больше понимания о том, как может себя вести функция g(), её контракт выражен возвращаемым типом и способов его нарушить (в идеале) у автора g() просто нет.
А насколько внимателен к обработке ошибок будет пользователь... это его выбор, самое главное, что он не вынужден следить за чужими ошибками и не создаёт их кому-то ещё по стеку выше или ниже, о ком он даже не знает
Ещё не стоит забывать и о том, что монады – не только про обработку ошибок, их функционал несколько шире, это, например, возврат какой-то дополнительной информации или даже возврат полноценного лога. Или более сложный пример – корутины, по сути, тоже монады, просто другая их форма, предназначенная для другой цели
По хорошему для этого юзают F[+_,+_], который для безошибочных функций отдает F[Nothing, T], для ошибочных F[Error, T]и собирает их F[Err1|Err2, T] для f flatMap g
Что насчёт оверхеда? Если там на каждый вызов в итоге происходит проверка успех/провал, то это то же самое что и коды ошибки, и это медленнее исключений в общем случае
Обсуждают сегодня