Почему обнуляемые операторы явного приведения LINQ вызывают недопустимые исключения формата для пустых значений?
Во-первых, Я знаю, что на этот вопрос можно ответить простым ответом, что пустая строка не является нулевым значением. Кроме того, я только недавно обнаружил операторы приведения в начале года с помощью другого вопроса о стеке, и у меня нет большого опыта работы с ними. Тем не менее, причина, по которой это не совсем так просто, заключается в том, что эти операторы приведения в сочетании с оператором объединения NULL считаются элегантным решением для работы с ошибочными состояниями, такими как отсутствие элементов или атрибутов в выражениях LINQ. Я начал использовать подход, описанный ScottH в «Улучшение запаха кода LINQ ...» и ScottGu «Оператор объединения с нулевым значением (и его использование с LINQ)» как способ защиты против недействительных / отсутствующих данных в сжатой и полу-элегантной форме. Насколько я могу судить, это, кажется, одна из мотиваций для размещения всех перегрузок приведения в классах LINQ в первую очередь.
Итак, на мой взгляд, вариант использования работы с отсутствующим значением - это еще не все. отличается от работы с пустым и в связанных статьях, этот подход рассматривается как хороший способ справиться с такими ситуациями.
Сценарий:
int length = (int?)elem.Attribute("Length") ?? 0;
Если атрибут @Length отсутствует, приведение приводит к нулевое значение и ?? оператор возвращает 0;
Если атрибут @Length существует, но пуст, приведение выполняется внутренне к int.tryparse и генерирует исключение формата. Конечно, для моего использования я бы хотел, чтобы это не было, и я просто возвращал бы null, чтобы я мог продолжать использовать этот подход в моем и без того запутанном коде LINQ.
В конечном итоге это не так уж и много, что я могу ' Эти статьи, кажется, предлагают (или, по крайней мере, привлекают внимание) улучшенный / альтернативный подход для работы с необязательными значениями
В моем случае необязательные значения иногда бывают в форме отсутствующих элементов или атрибутов, но ] также представлены в виде пустых элементов или значений
Описанный подход работает, как ожидалось, для отсутствующих значений, но не работает для пустых значений
Код, который следует описанному подходу, кажется, защищает против отсутствия необязательных значений, но на самом деле хрупок и ломается в конкретном случае. Меня беспокоит видимость защиты, когда на самом деле вы все еще находитесь в зоне риска
Это можно подчеркнуть, заявив, что оба связанных примера завершаются ошибкой с исключением времени выполнения, если целевой элемент существует, но пуст
Наконец, похоже, ключевой вывод заключается в том, что описанный подход отлично работает, когда у вас есть контракт (возможно, через схему), который гарантирует, что элемент или атрибут никогда не будут пустыми, но в случаях, когда этот контракт не существует, это подход недействителен и необходим альтернативный