.NET und C# ohne Web?
Правда? А если написать нормально?
Это ты называешь нормально? :) За такое "нормально" тоже надо отрывать руки :)
Т.е. мало того, что ты поменял типы данных у стороннего объекта с int на int?, так ты еще добавил дополнительный геттер туда, где он нахрен не нужен. И все этот огород из-за того, чтобы ты не любешь исключения :D
Есть еще по крайней мере пара способов сообщить об ошибке.
Ага, вернуть номер ошибки как всатые добрые 70-е :)
Ты пытаешься сказать что int?.HasValue
не дает тебе достаточно информации чтобы понять было значение получено и присвоено или это не получилось?
Самому не смешно?
Не смешно. Особенно, когда ты рассказываешь, что пишешь софт для производства. int.Parse кидает не только FormatException. Если у тебя входная строка null (а ты, я вижу любишь возвращать null'ы), то твой подход просто проглотит исключение и будешь ты долго и упорно искать причину проблемы, которая лежит за пределами int.Parse
Правда? А если написать нормально?
someObject.Val1 = int.Parse(strVal1);
someObject.Val2 = int.Parse(strVal2);
someObject.Val3 = int.Parse(strVal3);
someObject.Val4 = int.Parse(strVal4);
someObject.Val5 = int.Parse(strVal5);
if(!someObject.HasAllValues)
logger.Error ("Can't parse value");Имхо здесь 2 возможные проблемы. В примере независимые вызовы. Если же последующие вызовы зависят от результата предыдущих, то необходимо перед каждым вызовом ставить проверку и обработку возможных проблем. И кроме того, если одна функция не прошла, возможно нет смысл прогонять остальные. Ну и кроме того обработку исключительного состояния можно организовать на любом уровне стека. А так придется тащить HasAllValues еще куда-то,
поменял типы данных у стороннего объекта
------
Я просто скопипастил твой код - ленивый Я, лениво писать тип в каждой строке.
чтобы ты не любешь исключения
-----
Над мал-мал на рЮсская языка переводить...
Что до исключенй - когда надо - пользуюсь. Но - да - предпочитаю код где они не нужны. не не используются, а не нужны.
твой подход просто проглотит исключение
-----
Как можно проглотить то чего нету?
Ну посмотри на это сбоку.
Есть метод bool TryParse(string source, out int val)
Предлагается замена int? Parse(string source)
Все тоже самое только bool и int упакованы в int?
Никаких других преимуществ или проблем - нету. Просто нету. неоткуда им там появится.
а чем отличается out от ref
если имеем ин параметры и оут параметры, то реф совмещении обоих.
Вот типа псевдокода
void abc(int [in] a) { print(a);}
void abc(int [out] out a) { a= 3;}
void abc(int [ref] ref a) { print(a); a= 3;}
оут параметр выдается наружу и присваивается исключительно внутри функции.
реф может инициализироваться вне функции
Тебе сразу показывается проблемное место.
не нужно забывать что действие может быть ошибочным, а может быть "неверным".
Ну вот есть у меня файл с данными на 1000 строк, строки могут содержать ошибочные данные, но в любом случае мне нужно прочитать весь файл.
Что будет делать с сотней исключений? Радоваться что нас бросило в место исключения? Скорее скажем, что проигнорировать. Не зная, что в другом месте это уже будет ошибкой 
Если же последующие вызовы зависят от результата предыдущих
-----
У Parse()? Нее, точно не зависят.
Может зависеть состояние сомеОбект, но его не рассматриваем.
Потому как если станем рассматривать, то код поменяется на присвоение строки проперти (через прокси-класс) и парсинг спрячется внутри.
возможно нет смысл прогонять остальные
-----
Азы - проход должен выявить максимум проблем в исходных данных.
Т.е. парсить надо каждое значение и сообщать надо об каждой ошибке в данных.
тащить HasAllValues еще куда-то
-----
ООП говорит что ничего никуда тащить не надо - надо получить из объекта точное описание проблемы и скинуть полученное в лог.
Не написал потому как ленивый... да и не эта проблема рассматривается.
не нужно забывать что действие может быть ошибочным, а может быть "неверным".
Нет. Надо рассматривать встзречу определенного состояния, как такого, когда можно и нужно продолжать работу и когда работу продолжать нельзя. Потому что ИСКЛЮЧИТЕЛьНАЯ ситуация. Если файл нужно дочитать до конца, то выбрасывать исключение нет смысла - "ошибочные" данные это на самом деле не ошибочные, а такие, которые мы обрабатываем иначе и идем дальше.
Я просто скопипастил твой код - ленивый Я, лениво писать тип в каждой строке.
А ты не поленись и напиши. И тогда ты поймешь, что ты поменял типы данных в стороннем объекте.
Над мал-мал на рЮсская языка переводить...
чья бы корова мычала :)
ленивый Я, лениво писать тип в каждой строке.
Как можно проглотить то чего нету?
Его нету из-за того, что оно проглочено. Или ты думаешь, что TryParse имплементированно не через Parse? 
Ну посмотри на это сбоку.Есть метод bool TryParse(string source, out int val)Предлагается замена int? Parse(string source)Все тоже самое только bool и int упакованы в int?Никаких других преимуществ или проблем - нету. Просто нету. неоткуда им там появится.
Ну во-первых, подозреваю, что out появилось раньше, чем int?.
Во-вторых, разница в том, что в одном случае используются примитивы, а в другом контейнер.
Ну и в-третьих, разница в семантике. В одном случае проверка на "удалось ли распарсить", а в другом "удалось ли записать значение в переменную".
Что будет делать с сотней исключений?
-----
Разве это проблема? Это фигня, а не проблема.
Реальная проблема - либо надо тру-катчить каждый парсе, что даст ооочень приятный код, либо не будут отловлены все непарсимые данные и тогда будет реальная проблемa...
Мелкомягких надо было душить в колыбели, да.
Вы просто завидуете их успеху. ))))
Корявая оракловская джава лучше? Может Линукс, которому, чтобы им пользоваться, нужно посвятить жизнь? Или язык для старичков С++? Старички гордятся, что когда-то в 90-х, когда они были молодыми, оседлали тренд и теперь сидят на нём безвылазно, а никто из молодых нормально больше к ним войти не способен, и стараются сделать так, чтобы в будущем это только закрепилось - наваливают в него ещё сложностей. Ну или джаваскрипт - как из простого языка для двигания кнопочек по страничке и переключения переключателей попытаться сделать звездолёт на все случаи жизни. До сих пор пытаются - уже почти четверть века.
У Parse()? Нее, точно не зависят.
Ну мы жздесь не конкретно Parse обсуждаем. Мы говорим о обработке исключительного состояния и о том, что лучше - усключение или null
Азы - проход должен выявить максимум проблем в исходных данных.Т.е. парсить надо каждое значение и сообщать надо об каждой ошибке в данных.
Нет. Это условие зависит от задачи. Мы имеем сотню вложенных или вызываемых одна за другой функций, которые зависят друг от друга. Первая не смогла отработать и вернула неправильный результат. Можно подождать пару часов, пока отработают остальные. Результат будет одним и тем же - невозможно обработать данные.
Это не обязательно маска графической оболочки, где нужно отметить все незаполненные поля. Это может быть и импорт, где уже первая строка показывает, что формат файла неправильный.
ООП говорит что ничего никуда тащить не надо - надо получить из объекта точное описание проблемы и скинуть полученное в лог.
Лог к программе не относится, это средство для протоколирования, ООП такое не говорит и говорить не может. Обработка ошибок это не только сообщение о них юзеру, но и вyбор стратегии - а что проге делать дальше.
Мелкомягких надо было душить в колыбели, да.
Без мелокомягких мы бы имели сейчас пачку непохожих друг на друга линукс дистрибутивов, воевавших между собой за аудиторию, предлагающих каждый свой подход к написанию приложений, в которых "стандартный" С++ работал бы по-разному (следствие войны ОС - как сейчас в браузерах каждый гнёт веб-стандарты под себя и старается что-то нестандартное ввести), и убогие мобильные системы, пытающиеся выдать себя за десктопные со своими "мобилками с подключаемыми мониторами", где на твои 32-50 дюймов (у кого какие мониторы) тебе вываливают матрицу 4х5 кнопок размером с мой кулак и ни в чём себе не отказывай.
подозреваю
-----
Не подозревай - нуллабельные типы были раньше.
Не встроенные, но сторонние.
Сути это не меняет.
Или ты думаешь, что TryParse имплементированно не через Parse?
------
А для меня есть хоть какая-то разница как оно имплементировано?
В одном случае проверка на "удалось ли распарсить", а в другом "удалось ли записать значение в переменную".
-----
Гыыы?!!!
Никакой разницы.
Ну разве что результат попытки упакован со значением и проверку можно производить в удобное время.
Или ты хочешь сделать так
bool res1 = int.TryParse(myStr1, out int val1);bool res2 = int.TryParse(myStr2, out int val2);
bool res3 = int.TryParse(myStr3, out int val3);
и т.д.
и сказать что это правильно?
P.S. Кстати, вспомнил, в Шарпе есть и подобие union type - OneOf. Можно возвращать OneOf<int, string> или int или строку с ошибкой.
Это уже что-то типа кастомных вые...онов, монад и прочее сектантство-культизм.
Тогда что-то вроде OptionalInt возвращаем.
int?
Джентельмены, я не сишник, а чем отличается out от ref и что такое кортеж? Чем кортеж отличается от массива?
В шарпе кортеж это набор разнотипных данных. По сути просто класс с полями, но который не специально создаёшь, а чтобы по месту, обычно в контексте одной функции, что-то быстро вернуть-отправить. В шарпе есть ещё один костыль для этого - анонимные типы. И ещё более высокоуровневый костыль - DTO - Data Transfer Object - но то не только в шарпе. Хорошо было бы, если бы это всё заменили чем-то одним.