Вызов Console.WriteLine (ex.Message) для предотвращения предупреждения - PullRequest
Новая
       13

Вызов Console.WriteLine (ex.Message) для предотвращения предупреждения

4 голосов
/ 29 июня 2009

Обычно мы отлавливаем исключения на верхнем уровне кода, такого как GUI (формы).

Но у меня обычно такой код 

try
{
}
catch(Exception ex)
{
  Console.WriteLine(ex.Message);
  MessageBox.Show("Application has encountered error....");
}

Я мог бы просто перехватить (Исключение) без идентификатора, потому что мне не нужно сообщение во время выполнения, но для отладочной сборки, конечно, удобно разбить в операторе catch. Поэтому я обычно пишу Console.WriteLine, чтобы предотвратить много предупреждений о неиспользуемой переменной ex. У меня есть много случаев Console.WriteLine (ex.Message) в моем коде. Снижается ли эта экономичность?

Примечание. Изменен заголовок с "Имеет ли Console.WriteLine (ex.Message) снижение производительности?" на «Вызов Console.WriteLine (ex.Message) для предотвращения появления предупреждающего сообщения»

Ответы [ 6 ]

11 голосов
/ 29 июня 2009

Это многократный вопрос в 1, поэтому я постараюсь развернуть его:

Во-первых 

try{
  ...
}
catch(Exception) 
{
}

Совершенно допустимый синтаксис. Добавление Console.WriteLine (ex.Message) просто для компиляции без предупреждения не является правильным решением.

Во-вторых

Console.WriteLine не является правильным способом для диагностики, посмотрите на Trace.WriteLine или, что еще лучше, Каркас ведения журнала . Конечно, Console.Writeline имеет стоимость, стоимость не слишком серьезна, тем не менее, звонок сделан, и у него есть стоимость.

В-третьих

Иногда лучше аварийно завершить работу, он заставляет вас решить проблему с корнем, по крайней мере, выполните Debug.Assert , если происходит что-то действительно плохое.

6 голосов
/ 29 июня 2009

Вы можете создать метод расширения, который будет отфильтрован в режиме отладки. 

public static Exception
{

    [Conditional("DEBUG")]
    public static void Dump( this Exception ex )
    {
        Console.WriteLine( ex.ToString() );
    }
}

Или даже лучше ... 

public static Exception
{
    public static void Log( this Exception ex )
    {
#if DEBUG
        Console.WriteLine( ex.ToString() );
#endif
        Logger.WriteLine( ex.ToString() );
    }
}

Тогда в вашем коде замените Console.WriteLine( ex.ToString() ) на ex.Log();

Однако, как правило, само исключение будет скорее проблемой производительности, чем выводом на консоль.

3 голосов
/ 29 июня 2009

Лучшим выбором может быть System.Diagnostics.Debug.WriteLine (ex) или System.Diagnostics.Trace.WriteLine (ex). Отладка делает что-то только в том случае, если символ DEBUG определен, а Trace только что-то выполняет, если определено TRACE. По умолчанию ваша сборка релиза не будет содержать символ DEBUG.

2 голосов
/ 06 января 2010

Чтобы избежать получения предупреждения: «переменная ex объявлена, но никогда не используется» в операторе catch, и также для просмотра информации, связанной с исключением, выполните следующие действия: 

try
{
    ...
}
catch(Exception)    // avoid warning
{
   // set break point inside exception
}

Установите точку останова внутри исключения и посмотрите на переменную отладчика $ exception в любом окно быстрого просмотра, окно местных жителей или окно просмотра в Visual Studio (2008).

2 голосов
/ 29 июня 2009

Все имеет стоимость исполнения. Вопрос в том, значительна ли производительность.

В этом случае, я думаю, лучше задать вопрос, где вывод происходит в приложении winforms и почему вы отображаете только ex.Message, а не ex.ToString (). Зачем выбрасывать информацию?

0 голосов
/ 29 июня 2009

В C # есть стоимость, которая не является незначительной при отлове исключения. Проверьте сами, напишите что-то вроде этого:

  • Создать список строк
  • В этом списке 25% из них составляют число, а остальные - одну букву.
  • Запустите цикл for, просматривая каждый список и выполняя int foo = (int) myList [0], но оборачивайте его в try / catch.

Увеличьте ставку до 50%, затем до 75%, затем до 100%. 100% будет немного медленнее, но ненамного.

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

...