.е. ты сообщишь челу об ошибке и он ее исправит...

Нет. Ты говоришь о текущих ошибках ввода. Типа сидит оператор и пытается понять, что то там не так. Но не всегда есть оператор. Например система автоматически выбирает файлы из папки. И нашла там какую то хрень. Или идёт многоуровневая обработка данных и первый уровень гордо отрапортовал - я насчитал какую то хрень. Дальше отправлять? На следующий уровень... В этом случае обработку нужно прервать. Причем эта необходимость - это условие задачи. То есть я, как программист, вижу, что дальнейшая обработка невозможна или бессмысленна. В этом случае эксцептион и имеет преимущество. Особенно на вебе. Где бы подобная ошибка не произошла - ексцепшион выбросит курсор в централизованное место обработки исключений, которое и составит правильный ответ сервера.

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

Ещё раз. Мы имеем дело со случаем, когда продолжение работы невозможно. От слова совсем. Ну оборвался файл и пошел мусор. Какой парсер ты будешь к мусору искать?

И ООП ничего не говорит о логах. Или о том, как объект должен реагировать на ошибку. И даже о том, что он должен делать с ошибкой. Например это веб приложение без логов и ошибка произошла на уровне уровня доступа к базе данных. Задача - сформировать правильный ответ сервера. Но уровень не имеет выход на транспортный уровень и ошибку нужно догнать до слоя API. Где и будет сформирован и отослан ответ.

Таким образом каждое приложение имеет свою стратегию обработки ошибок, централизованную и стандартную для всего приложения, а не просто в логи пишет.

Вроде как тема несколько другая - иметь оут-параметер или упакованный возврат.

Смотри, не моя тема, умолкаю😀