int bar() {
  if (!foo()) { 
    return ERR_SOME_ERROR;
  }
}

как правило, в этот момент я уже решил задачу. Либо искать дальше bar(), и так далее.

Скажу так: мне повезло, что в моём продукте исключений нет и мой непосредственный коллега разделяет моё отношение к ним.
Мой менее непосредственный коллега во флагманском продукте юзает исключения. Он хорошный программист, грамотный и дотошный, но непогрешимых нет. Поэтому я периодически запускаю WinDBG, когда юзер присылает минидамп крэша, и тыкаю коллегу носом в тот throw, для которого он опять забыл catch.

А вот если catch не забыли, но сработал не тот, который должен, это дебажить гораздо сложнее.

Но ведь с исключениями будет абсолютно то же самое

Ты либо увидешь try/catch и "решишь задачу", либо пойдешь искать вызовы функции bar

Гипотетически вроде бы да, но практически - я всё это на своей шкуре испробовал, и терпеть не могу исключения. Хотя есть определенные паттерны, в которых они очень удобны. Эти паттерны можно завернуть в большую функцию или модуль с nothrow интерфейсом, и перепроверить, что внутри всё точно ловится.

да ну ты гонишь...
Как можно catch забыть?

А как вы без исключений осуществляете доступ к файлу "hello.txt" в папке "world"?

Конкатенация путей может бросить bad_alloc

не юзаю std::filesystem, потому что он до сих пор не везде мне доступен. 2021 год, да.

Слава Богу что на такое "забыл catch" создаётся дамп. Ведь если не юзать исключения и забыть обработать код ошибки (аналог "забыть catch"), то можно не получить никакого падения вообще. Более того можно пойти весело дальше работать с сломанными инвариантами и повредить данные клиентов или упасть хз где хз по какой причине

Поэтому без nothrow обертки это неюзабельно

не важно, std::filesystem это или нет, у вас есть работа с файловой системой, и, если да, она собирается падать на bad_alloc или использовать статический буфер / alloca?

Так вот именно, что на "забыл" создаётся, когда это поток, и то это лично я заморочился, потому что я задолбался, что косячит он, а пишут юзеры мне. А вот на "ой, не тот catch" дамп не создашь.

в жизни не видел std::bad_alloc

вот буквально, 0 раз за 9 лет в проде была такая проблема

а вы и в 32-битную эпоху не работали, видимо

почему же, работал несколько лет

и некоторые приложения у нас на винде до сих пор 32-битные. а какая связь?

точнее, связь я понял, наверное. Ну вот мой продукт и есть 32-битный, 0 проблем такого рода.

32-битное приложение при попытке аллокации блоков порядка 64МБ и использовании памяти порядка 600МБ рано или поздно свалится в bad_alloc