.NET und C# ohne Web?
поменял типы данных у стороннего объекта
------
Я просто скопипастил твой код - ленивый Я, лениво писать тип в каждой строке.
чтобы ты не любешь исключения
-----
Над мал-мал на рЮсская языка переводить...
Что до исключенй - когда надо - пользуюсь. Но - да - предпочитаю код где они не нужны. не не используются, а не нужны.
твой подход просто проглотит исключение
-----
Как можно проглотить то чего нету?
Ну посмотри на это сбоку.
Есть метод bool TryParse(string source, out int val)
Предлагается замена int? Parse(string source)
Все тоже самое только bool и int упакованы в int?
Никаких других преимуществ или проблем - нету. Просто нету. неоткуда им там появится.
Мне исключения не нравятся, потому что:
1) громоздкий синтаксис
2) пишутся сильно далеко от когда, который эти исключения бросает (где-то в конце функции)
Это понятно. Но эти кортежи в возврате вместо аут-параметров - это прям ням-ням. Не знаю почему, но меня постоянно бесило после названия функции вспоминать, что там надо пачку аутов определить, прерывать ход своих мыслей по коду и идти определять эти ауты.
Не знаю почему, но я так с ходу и не вспомню, когда писал (и писал ли вообще) функцию с out параметрами :)
DateTime не высчитывает немецкую календарную неделю.
а в алгоритме расчёта ты получаешь и неделю и год.
можно конечно написать две функции, но это во-первых копипаста будет и во-вторых не перфомантно.
Может быть я чего-то не понимаю, то год - это проперти у DateTime. Там ничего писать не надо. Надо сделать только экстеншен метод для DateTime, который бы рассчитывал немецкую календарную неделю.
Они должны быть простыми,
Нет. Они могут быть реально сложнее чем сам код. Просто это не продуктивный код. Если там что то неправильно это плохо, но не критично.
Не кажется, что тут лишнее звено?
Нет. Ввод непродуктивного проверяющего кода не гарантирует отсутствие ошибок. Но снижает их и снижает очень ощутимо. Просто надо понимать цели иправильно использовать. И помнить, что продуктивный код работает и с юниттестами и без них. И юниттесты нужны в первую очередь не для поиска ошибок, а для проверки кода на критерии. Если юниттест обвалился, то проишодит это всегда в среде разработки и тестирования и никогда в продуктивной среде. То есть есть возможность руками залезть и разобраться, кто виноват.
Проблема юнит тестов в том, что либо их мало и они тестируют всякую мелочную чушь, которая и так очевидна, либо их должно быть настолько много, чтобы они всё покрывали, но тогда разработка усложняется раза в два.
Это уже философия. Проблема в том, что программисты либо неопытные либо дорогие. Что начальство тупое либо это не наше начальство. либо-либo
Это было бы смешно, если бы не было бы так глупо :)
Интерфейс - это абстракция. Кортеж - конкретика.
Если разрабатывать софт опираясь на конкретные объекты, то рано или поздно будешь похоронен в лесу костылей. При этом костыли будут непонятным образом влиять друг на друга и все это это будет совершенно нетестируемо.
Я согласен в общем. Новичкам, и мне в том числе, не хватает опыта, чтобы уже знать и предсказывать, где могут возникнуть сложности от попыток слукавить и отойти от правил тут и там. Но на практике часто требуется именно наговнокодить несмотря на все последствия - всё горит, заказчик требует. А если заказчик при этом ещё и любые бабки платит, то сеньор-архитектор менеджер стоит над тобой и бьёт по рукам
уже за попытки сделать по-уму, а не тупо быстро наговнокодить.
Этот подход называется "хуяк, хуяк и в продакшен". Хорошего в этом мало ;)
А на практике - платят неплохие бабки. ))) Главное, на собесе это не говорить.
Там уже не про яву - просто вы упомянули джаваскрипт, что там лучше. Я вспомнил, что вот есть очень известный и распространённый продукт, где перешли с джаваскрипта на шарп. Причём джаваскрипт выкинули вообще - всё, deprecated. Сначала подержали несколько версий параллельно - можно было и на том, и на том писать, а потом выкинули. Почему, как вы думаете?
А заказчик переименовал вордовский бинарный файл в текстовой и запустил импорт
Ты неправ. Заказчик набрал студентов и они переименовывают все файлы из системы чтобы найти который из них может обвалить приложение.
Это самая распространённая практика думаю 
на самом деле
------
он не выбрасывает исключений. хандлил ли он что-то внутри себя - не играет никакой роли.
Я говорю, что все зависит от задачи.
-----
Хи-хи... У нас уже правильность кода начала зависеть от того возвращаем мы два отдельных элемента и их упаковали перед возвратом...
о обработке исключительного состояния и о том, что лучше - усключение или null
-----
Вроде как тема несколько другая - иметь оут-параметер или упакованный возврат.
Исключений - не будет, возврата null тоже,
Результат будет одним и тем же - невозможно обработать данные.
------
Результат будет существенно разным;
В случае когда отвалил по первой встреченной пролеме ты не имеешь информации об остальных ошибках.
Т.е. ты сообщишь челу об ошибке и он ее исправит... как сможет... вплоть до того, что удалит строку с ошибкой и по окончании импорта/парсинга введет в ручном режиме.
После чего будет импортировать/парсить снова и уткнется в следующую ошибку и будет вынужден снова что-то делать.
А чел - ленив и допускает ошибки.
Так что имея необходимость повторить импорт/парсинг 10-15-100 раз обязательно сделает что-то неправильно.
В случае когда получается полный список того что невозможно распарсить - выполняется однократная обработка всех ошибок в ручном режиме.
В этом случае неправильных действий будет гораздо меньше.
Можно подождать пару часов, пока отработают остальные.
-----
Ну так можно и 100 раз по паре часов ждать пока найдется место которое нельзя распарсить. 
ООП такое не говорит и говорить не может.
------
ООП говорит что объект должен отвечать за себя сам.
В данном контексте - сообщить что не так со значениями пропертей.
где уже первая строка показывает
-----
Пыхх...
Ну значит возьмешь нужный парсер, делов то - запросить его у фабрики.
Но вопрос то был не в этом.
А заказчик переименовал
-----
У операторов, кстати, регулярная проблема - пришел файл, получили ошибку импорта, открыли, отредактировали, сохранили... pissec.
Потому как получили текстовый файл, открыли Вордом (.тхт) или Ехцелом (.цсв) и сохранили в формате по умолчанию.
Он будет очен рад протоколу ошибок
-----
Поверь - будет лучше поиметь охрененный список из всех ошибок, чем мудохаться с каждой не зная сколько их еще осталось.
Она никак не изменилась по сравнению со "старым" синтаксисом.
-----
Именно это и напрягает.
Когда ты декларируешь переменную в цикле - она доступна только в цикле.
А когда в вызове функции - вываливается за пределы вызова.
Для меня данный момент создает некоторый дискомфорт.