А как вообще обрабатываются монадические ошибки (не знаю как их правильно назвать) в реальном коде?

То есть на уровне 1 вложенности можно написать чтото типа '?' rust, ну тоесть

void g() {
func1()?;
func2()?;
}

А что будет на следующем уровне вложенности? Тоесть как вызвать функцию g? Тоже ставить вопросики типа

g()?;

Не получится ли тогда, что все везде будут ставить вопросы не задумываясь, и в результате получим теже самые исключения только в профиль?

Да, это возможно, но есть существенная разница.

В случае с исключениями, пользователь функции g() может и не знать, прилетит ли ему исключение, а если да – то какое и откуда, из func1(), func2()?

По сути, автор функции g() может просто взять и забить переложить ответственность за обработку ошибок вызываемых им функций на пользователя функции g(), по сути, оставляя прямое взаимодействие между пользователем функции и частью внутренней имплементации – func1(), func2(). Это не очень красиво, у нас протекла абстракция в случае, если требуется хоть сколько-нибудь нетривиальная обработка ошибки.

В случае же с монадами... Ну, автор функции g(), в идеале, явно укажет тип возвращаемого значения. А ещё ему придется позаботиться, чтобы в случае ошибок, возвращался один и тот же тип ошибки, ведь func1() и func2() могут вернуть разные монады для обработки разных типов ошибок. В любом случае, у пользователя больше понимания о том, как может себя вести функция g(), её контракт выражен возвращаемым типом и способов его нарушить (в идеале) у автора g() просто нет.

А насколько внимателен к обработке ошибок будет пользователь... это его выбор, самое главное, что он не вынужден следить за чужими ошибками и не создаёт их кому-то ещё по стеку выше или ниже, о ком он даже не знает

Ещё не стоит забывать и о том, что монады – не только про обработку ошибок, их функционал несколько шире, это, например, возврат какой-то дополнительной информации или даже возврат полноценного лога. Или более сложный пример – корутины, по сути, тоже монады, просто другая их форма, предназначенная для другой цели

>  А ещё ему придется позаботиться, чтобы в случае ошибок, возвращался один и тот же тип ошибки

Ну в нормальных яп типов ошибки (точнее базового класса) и так немного, 1-2 штуки. Так что с этим проблем обычно нет.

Так что мне кажется, что одно из немногих преимуществ таких "исключений" - это больше ясности, что может выбросить исключение а что нет. Но для этого мне кажется можно и noexcept допилить

А там разве не .then/.else для обработки ошибок?

да блин noexcept уже принципиально не допилишь. Должно быть наоборот - методы которые кидают дополнительно помечены

как со старым throws

только с ним была скорее проблема полиморфизма

Хм... Ты пробовал писать noexcept код?

да, проблема не в том чтобы его писать, а в плохом значении по умолчанию

скажем надо тебе старый код модернизиировать, покрыв noexcept'ами

и пошла возня

Со старым throw
И возможно новым throws
))

Ну не знаю, у меня проблемы типа конкатенация путей умеет бросать bad_alloc была

тут есть нюанс. bad_alloc это исключение которые довольно-таки многие программы не обрабатывают )

в отличие от других

Ну вот для начала надо считать, что аллокатор - noexcept

в расте такой же принцип примерно - там есть механизм а-ля исключений но только для ошибок аллокации и паник

По хорошему для этого юзают F[+_,+_], который для безошибочных функций отдает F[Nothing, T], для ошибочных F[Error, T]и собирает их F[Err1|Err2, T] для f flatMap g

Существуют ли способы проверить, что какой-либо метод класса реализован именно в классе T, а не в одном из его родителей?

struct A { void foo(); };
struct B : A { void bar(); };

static_assert(is_B_method(&B::bar));
static_assert(!is_B_method(&B::foo));

Способы, требующие явного перечисления родителей каждого класса, очевидно, не подходят

struct A { void foo(); };
struct B : A { void bar(); };

static_assert(is_B_method(&B::bar));
static_assert(!is_B_method(&B::foo));

не подойдет https://en.cppreference.com/w/cpp/types/is_member_function_pointer ?