Llamar a Console.WriteLine (por ejemplo, Mensaje) para evitar mensajes de advertencia

Question

Por lo general, detectamos excepciones en el nivel superior de un código como la GUI (formularios).

Pero generalmente tengo este tipo de código

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

Podría capturar (Excepción) sin el identificador porque no necesito el mensaje en tiempo de ejecución, pero para la compilación de depuración, es conveniente romper la instrucción catch. Por lo tanto, generalmente escribo una Console.WriteLine para evitar muchas advertencias de la variable ex no utilizada. Tengo muchos casos de Console.WriteLine (por ejemplo, Message) en mi código. ¿Este rendimiento de costo disminuye?

Nota: ¿Se cambió el título de " ¿Console.WriteLine (por ejemplo, Message) tiene un costo de rendimiento? " a " Calling Console.WriteLine (ex.Message) para evitar el mensaje de advertencia "

Answer 1

Esta es una pregunta múltiple en 1, así que intentaré desenrollarla:

Primero

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

Es una sintaxis perfectamente válida. Agregar una Console.WriteLine (ex.Mensaje) solo para que compile sin avisar no es lo correcto.

Segundo

Console.WriteLine no es la forma correcta de hacer diagnósticos, mira Trace.WriteLine o mejor aún un Marco de registro . Por supuesto, Console.Writeline tiene un costo, el costo no es demasiado serio, sin embargo, se realiza una llamada y tiene un costo.

En tercer lugar

A veces es mejor bloquearse, te obliga a solucionar el problema raíz, al menos haz un Debug.Assert si sucede algo realmente malo.

Answer 2

Puede crear un método de extensión que se filtre en modo de depuración.

public static Exception
{

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

O incluso mejor ...

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

Luego, en su código, reemplace Console.WriteLine( ex.ToString() ) por ex.Log();

Sin embargo, en general, la excepción en sí misma será más un problema de rendimiento que el volcado a la consola.

Answer 3

Una mejor opción podría ser System.Diagnostics.Debug.WriteLine (ex) o System.Diagnostics.Trace.WriteLine (ex). La depuración solo hace algo si el símbolo DEBUG está definido y Trace solo hace algo si TRACE está definido. Por defecto, su versión de lanzamiento no incluirá el símbolo DEBUG.

Answer 4

Todo tiene un costo de rendimiento. La pregunta es si el costo de rendimiento es significativo.

En este caso, creo que las mejores preguntas son a dónde va la salida en una aplicación winforms y por qué solo muestra ex.Message y no ex.ToString (). ¿Por qué tirar información?

Answer 5

Para evitar recibir la advertencia: " La variable 'ex' se declara pero nunca se usa " en una declaración de captura, y también para ver la información asociada con la excepción, haga lo siguiente:

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

Establezca un punto de interrupción dentro de la excepción y observe la variable $ depurador excepción en la ventana de observación rápida, la ventana local o la ventana de observación dentro de Visual Studio (2008).

Answer 6

En C # hay un costo que no es insignificante al detectar una excepción. Pruébelo usted mismo, escriba algo como esto:

• Crear una lista de cadenas
• En esta lista, haga que el 25% de ellos sea un número y el resto una sola letra.
• Ejecute un bucle for pasando por cada lista y haciendo una int foo = (int) myList [0] pero envuélvala en try / catch.

Aumente la tasa al 50%, luego al 75%, luego al 100%. El 100% será un poco más lento, pero no mucho.

En este ejemplo particular, la respuesta del mundo real sería usar Int32. TryParse en su lugar, pero esto muestra la penalización.