Локальная переменная c ошибка

После поиска я, похоже, не могу понять, почему компилятор C # жалуется, что локальная переменная dteDest не назначена в строке

 if (dteSrc == dteDest) {
 

Ошибка исчезнет, если я заменю строку

 DateTime dteSrc, dteDest;
 

с

 DateTime dteSrc, dteDest = DateTime.MinValue;
 

Насколько я вижу, код никогда не достигнет строки сравнения, если dteDest не инициализирован DateTime .Попробуйте проанализировать, для чего это параметр out.

Моя логика:

1. Если currentDataObj равно null, то booHaveOrigDate равно false, а первый if завершается ошибкой
2. Если currentDataObj не равен null, но не может быть преобразован в DateTime, тогда booHaveOrigDate равно false, а первый if завершается ошибкой
3. Дата-время.TryParse вернет false, если он не может преобразовать в DateTime это вместе с amp;amp; означает, что dteDest никогда не будет использоваться.

Простой пример кода

 void StrangeLogic(object srcData, object currentDataObj) {
   DateTime dteSrc, dteDest;

   bool booHaveNewDate = DateTime.TryParse(srcData.ToString(), out dteSrc);
   bool booHaveOrigDate = (currentDataObj != null) 
                          amp;amp; DateTime.TryParse(currentDataObj.ToString(), out dteDest);

   if (booHaveNewDate amp;amp; booHaveOrigDate) {
      if (dteSrc == dteDest) { 
          // Get a "use of unassignned local variable 'dteDest' 
          // unless dteDest = DateTime.MinValue beforehand
      }
   }
}
 

Также, если я изменю строку

 bool booHaveNewDate = DateTime.TryParse(srcData.ToString(), out dteSrc);
 

к следующему

 bool booHaveNewDate = (srcData != null) amp;amp; DateTime.TryParse(srcData.ToString(), out dteSrc);
 

затем компилятор жалуется, что srcDate также не назначен.

Может ли кто-нибудь указать мне правильное направление на то, чего мне не хватает — я не имею в виду проверку параметров и т. Д. Меня беспокоит, почему логика компилятора кажется обманутой использованием общей функции TryParse?

Дополнительная информация

Даже расширение логики по-прежнему выдает ту же ошибку (использование неназначенной локальной переменной)

 bool booHaveOrigDate;
if (currentDataObj != null) 
   booHaveOrigDate = DateTime.TryParse(currentDataObj.ToString(), out dteDest); 
else 
   booHaveOrigDate = false;

if (booHaveOrigDate) {
    if (dteSrc == dteDest) {
 

Похоже, что это то, что компилятор делает с проверкой null (currentDataObj != null), что мешает ему правильно определить, что dteDest не будет доступен, если не назначен

Измените его на этот код и никаких проблем (кроме возможных.toString() для нулевого объекта

 bool booHaveOrigDate = DateTime.TryParse(currentDataObj.ToString(), out dteDest); 
if (booHaveOrigDate) {
    if (dteSrc == dteDest) {
 

Ваша замена неверна, она должна быть:

 DateTime dteSrc = DateTime.MinValue, dteDest = DateTime.MinValue;
 

Однако вы должны использовать возвращаемую переменную TryParse , которая является bool, чтобы увидеть, сработал ли tryparse вместо этого, если ваш booHaveNewDate:

 DateTime dteSrc, dteDest;

if(DateTime.TryParse(srcData.ToString(), out dteSrc) amp;amp; DateTime.TryParse(currentDataObj.ToString(), out dteDest))
{
  if (dteSrc == dteDest) { 
      // Do your stuff here
  }
}
 

Теперь вам не нужно назначать даты в самом начале.

** Вы должны протестировать этот код перед использованием, он не является производственным кодом и может содержать ошибки

Компилятор формально корректен, присвоение dteDest (в качестве out параметра) является условным. В глазах компилятора этого может и не произойти. Компилятор не «понимает» логику, которая следует из TryParse() .

Здесь аналогичная ситуация:

 int f(int x)
{
   int r;

   if (x <= 5)  r = 1;
   if (x >  5)  r = 2;

   return r;  // error: use of uninitialized var
}
 

С другой стороны, кажется немного более логичным инициализировать с помощью

   DateTime dteSrc = default(DateTime), dteDest = default(DateTime);
 

хотя это то же значение (DateTime.MinValue).

Я могу ошибаться, но я не думаю, что компилятор пытается так тщательно проанализировать ваш код при сообщении об этой ошибке. В настоящее время я пытаюсь найти какой-либо источник для подтверждения моей теории. В то же время, я предполагаю, что это дизайнерское решение, потому что, если человеку требуется больше пары секунд, чтобы увидеть, что переменная не будет использоваться перед инициализацией, вероятно, лучшим решением для кодирования будет просто инициализировать ее нулем для начала, чтобы избежать путаницы.

Редактировать:

Ну, я немного осмотрелся, и хотя я нашел пару примеров людей, говорящих по сути то же самое, что и я, я не могу найти никакой официальной документации, подтверждающей это. Вот ответы, которые я нашел, хотя:

«Компилятор имеет полное право не знать вашу логику».

http://www.pcreview.co.uk/forums/use-unassigned-local-variable-error-t3067479.html

«… когда есть структура потока управления, он не может оценить ситуацию, потому что он не выполняет код, поэтому он не знает, присваиваются ли значения».

http://bytes.com/topic/c-sharp/answers/917965-why-am-i-getting-unassigned-local-variable-errors

dteDest не будет иметь установленного значения, если currentDataObj == null

Это сработает, если вы измените свою строку на:

 bool booHaveOrigDate = DateTime.TryParse(currentDataObj != null ? currentDataObj.ToString() : string.Empty, out dteDest);
 

логика компилятора, похоже, обманута использованием обычной функции TryParse

На приведенный выше вопрос проще всего ответить тем фактом, что когда компилятор компилирует ваш код, он не смотрит на то, что этот метод делает внутри, он просто смотрит на подпись. Он знает, что может возвращать логическое значение, которое может быть true или false, и он знает, что он устанавливает значение dteDest .

На самом деле это не ваша проблема. Проблема заключается в том, что следующая строка:

 bool booHaveOrigDate = (currentDataObj != null) 
          amp;amp; DateTime.TryParse(currentDataObj.ToString(), out dteDest);
 

Использует amp;amp; оператор, который не будет оценивать вторую часть, если первая часть имеет значение false. Это называется оценкой короткого замыкания и работает по теории, что если первая часть false, то не имеет значения, какова вторая часть — общий результат всегда будет false.

Таким образом, в этом случае dteDest никогда не устанавливается, и компилятор чувствует, что это проблема, даже если вы посмотрите на логику и скажете, что код никогда не будет выполняться, если он не установлен.

Простой факт заключается в том, что люди часто могут определить оптимизацию и особые случаи, которые находятся за пределами компилятора. Вы говорите так, как будто уже знаете, что можете решить эту проблему, просто проверив параметр в начале, а затем вернув, если он равен нулю.