.NET und C# ohne Web?
Заводи класс (который только тут и будет использоваться), возвращай объект - как замшелые старички учили. И не дай бог перепутаешь, в стеке или в куче у тебя это храниться будет! Помню, раньше ещё, в 90-х объясняли, что у стека и кучи разная производительсноть, и надо там всё тонко разбирать. С тех пор у памяти настолько возросла производительность, а объёмы настолько увеличились, что прежняя оперативка влезает в сегодняший процессорный кеш. Да и компиляторы стали настолько умными, что аллоцируют везде, где им вздумается, и предсказать точно, где там что выделится, нельзя. Ты обозначил в коде так-то и так-то, а компилятор умнее тебя и оптимизирует как захочет. А на собесах до сих пор по языкам с неуправляемой памятью и компиляторм на ИИ гоняют по кучам и стекам.
чувак, ты правильные вещи говоришь!
Может все же пойдёшь к нам работать?))
Да ладно! В яве нет генериков? :)
чувак, ты может почитаешь все же, о чем речь идёт?))
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/value-tuples
.е. ты сообщишь челу об ошибке и он ее исправит...
Нет. Ты говоришь о текущих ошибках ввода. Типа сидит оператор и пытается понять, что то там не так. Но не всегда есть оператор. Например система автоматически выбирает файлы из папки. И нашла там какую то хрень. Или идёт многоуровневая обработка данных и первый уровень гордо отрапортовал - я насчитал какую то хрень. Дальше отправлять? На следующий уровень... В этом случае обработку нужно прервать. Причем эта необходимость - это условие задачи. То есть я, как программист, вижу, что дальнейшая обработка невозможна или бессмысленна. В этом случае эксцептион и имеет преимущество. Особенно на вебе. Где бы подобная ошибка не произошла - ексцепшион выбросит курсор в централизованное место обработки исключений, которое и составит правильный ответ сервера.
Ну значит возьмешь нужный парсер, делов то - запросить его у фабрики.
Ещё раз. Мы имеем дело со случаем, когда продолжение работы невозможно. От слова совсем. Ну оборвался файл и пошел мусор. Какой парсер ты будешь к мусору искать?
И ООП ничего не говорит о логах. Или о том, как объект должен реагировать на ошибку. И даже о том, что он должен делать с ошибкой. Например это веб приложение без логов и ошибка произошла на уровне уровня доступа к базе данных. Задача - сформировать правильный ответ сервера. Но уровень не имеет выход на транспортный уровень и ошибку нужно догнать до слоя API. Где и будет сформирован и отослан ответ.
Таким образом каждое приложение имеет свою стратегию обработки ошибок, централизованную и стандартную для всего приложения, а не просто в логи пишет.
Вроде как тема несколько другая - иметь оут-параметер или упакованный возврат.
Смотри, не моя тема, умолкаю😀
вижу, что дальнейшая обработка невозможна
-----
Каким образом это определилось?
Тем, что не смогли распарсить поле?
Ой-ей - так оно - опциональное. Причем в первой версии требовалось нулевое значение для обозначения не заданности, а во второй - можно оставить просто пустым.
Какой парсер ты будешь к мусору искать?
-----
Мусорный, разумеется. 
Тем не менее - даже по мусору предпочту получить отчет по каждому полю на парсинге которого произошла ошибка.
И - да - даже в том случае когда происходит чисто автоматическая обработка импорта.
приложение имеет свою стратегию обработки ошибок
-----
При любой обработке ошибок - источником проблемы когда-нибудь будет заниматься чел.
Вот этому челу и нужна будет достаточно детальная информация для выявления причин.
У меня, например, писалась не только ошибка, а вообще все исходные данные с разметкой и результирующая распасовка по полям.
По каждой записи, с описанием всех возникших ошибок.
Очень, знаешь ли, помогало при выявлении проблем.
Каким образом это определилось?
Путем интенсивной мозговой деятельности 
Murr, ну ты же думаешь, когда программируешь? Итак, ты ставишь проверку и продумываешь стратегию поведения проги после нахождения исключительной ситуации. У тебя действительно в жизни встечалась только одна ошибка - "не смогли распарсить поле"? Да нет никаких полей в неправильном файле. От слова совсем. Это если брать импорт. В сложном импорте с несколькими файлами это может быть отсутствие одного из файлов. Это может быть вообще не импорт
даже по мусору предпочту получить отчет по каждому полю
Откуда в мусоре поля? 
Вот этому челу и нужна будет достаточно детальная информация для выявления причин.
2 Гб файл импорта, который случайно попал в прогу. 2 дня
прога пыхтела и никто не знал, как ее остановить. После чего прога вывалила 4Гб ценной информации по КАЖДОМУ полю, что оно не найдено 
И в конце скромно приписала - и вообще файл у вас не тот. Эти 4Гб детальной информации очень порадуют оператора, который не исправляет и не создает файлы импорта. Он их просто получает.
продумываешь стратегию поведения проги после нахождения исключительной ситуации
------
Я действительно думаю когда программирую.
Потому у меня в коде исключительные ситуации не связаны с тем какие данные обрабатываются и какие рассчеты производятся.
Это - издержки обучения - когда учили в языках никаких исключений не предусматривалось - надо было писать корректно работающий код.
Откуда в мусоре поля?
-----
А почемы ты думаешь что их там нет?
Хотя - да, их там нет. Впрочем, их нет и в корректном файле данных.
Потому как "поле" это то как прожка читает данные.
Прожка у тебя есть по определению - следовательно она будет читать поля из что-ей-там-дадут.
4Гб ценной информации по КАЖДОМУ полю, что оно не найдено
-----
Обеспечь достаточное количество пустого дискового пространства.
Остальное - забота того кто будет разбираться с ситуацией.
и никто не знал, как ее остановить
-----
Хреново же у вас пишут код... 
В комментах к видео о работе разрабом в Силиконовой долине встретил:
расскажите, пожалуйста, как на ваших местах работы (а вы уже побывали в нескольких именитых компаниях, о которых ваши зрители по бОльшей части пока что только мечтают) относятся к TDD-подходу или даже к DDD? И пользуются ли они метриками управления зависимостей при управлении архитектурой отдельных компонентов и проекта в целом, например, такими как REP / CCP / CRP?
Насколько канонично внедрен Agilie/Kanban? И интересно в целом, правда ли, что в Долине особо популярно (по сравнению с СНГ, например) следование заветам Роберта Мартина, Мартина Фаулера и других столпов индустрии или же на первом месте стоит только умение программиста "запиливать фичи быстро здесь и сейчас без оглядки на будущую поддержку"?
Почему то раньше имел субъективное мнение о "безупречности" (в разумных пределах) кода, рожденного в Долине, но некоторые ваши выпуски с рассказами о гиперактивных менеджерах, повышенном кортизоле из-за постоянного стреса и метриках, оценивающих количество фич в неделю пошатнули мою веру))
Можно ли где то встретить в коменте к мерж реквесту сообщение типа (абстрактный пример в вакууме):
"Переделай. Данный класс нарушает принцип устойчивости зависимостей SDP, т.к. его устойчивость меньше, чем устройчивость зависящих от него классов в соотношении 0.5 к 0.3"?
А у вас можно где-то встретить не то, что коммент к мерж реквесту, а хотя бы мнение коллег на кодревью, как выделено жирным? Что-то мне подсказывает, что вероятность стремится к нулю.
Сколько ни встречал описаний компаний, какие у них подходы введены, то это лишь то, к чему они как бы стремятся, а обычно в реальности всё раза в 2-3 хуже. А уж если аврал или "клиент сказал срочно надо - платит любые деньги!", то на все принципы плюют, кроме одного - "тяп-ляп и в продакшон... а там на поддержке поправим (если клиент её закажет)".
и никто не знал, как ее остановить
-----
Хреново же у вас пишут код...
В некотором ПО серверную часть просто раз в сутки перезагружают. Т.е. сами серваки перезагружают. И так делают уже много лет (точно больше 10). Потому что память течёт, и оказалось, что перезагружать раз в сутки тупо проще, чем искать оставшиеся места утечек. Проект, кстати, был успешным много лет, но потом скатился, но не из-за постоянных перезагрузок, а глупости руководства.