Calling Console.WriteLine(ex.Message) to prevent warning message

Question

We usually catch exception in the upper level of a code like the GUI (forms).

But I usually have this kind of code

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

I could just catch(Exception) without the identifier because I do not need the message on runtime, but for the debugging build, it sure is convenient to break at the catch statement. So I usually write a Console.WriteLine to prevent a lot of warning of unused ex variable. I have a lot of case of Console.WriteLine(ex.Message) in my code. Does this cost performance decrease?

Note: Changed title from "Does Console.WriteLine(ex.Message) have performance cost?" to "Calling Console.WriteLine(ex.Message) to prevent warning message"

Answer 1

Everything has a performance cost. The question is whether the performance cost is significant.

In this case, I think the better questions are where the output is going in a winforms application, and why you're only displaying ex.Message and not ex.ToString(). Why throw away information?

Answer 2

A better choice might be System.Diagnostics.Debug.WriteLine( ex ) or System.Diagnostics.Trace.WriteLine( ex ). Debug only does something if the DEBUG symbol is defined and Trace only does something is TRACE is defined. By default your release build will not include the DEBUG symbol.

Answer 3

This is a multiple question in 1 so I will try to unroll it:

Firstly

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

Is perfectly valid syntax. Adding a Console.WriteLine(ex.Message) just to get the thing to compile without warning is not the right thing to be doing.

Secondly

Console.WriteLine is not the proper way to do diagnostics, look at Trace.WriteLine or better still a Logging framework. Of course Console.Writeline has a cost, the cost is not too serious, nonetheless a call is made, and it has a cost.

Thirdly

Sometimes its better to crash, it forces you to fix the root problem, at least do a Debug.Assert if something really bad happens.

Answer 4

You can create an extension method that gets filtered out in debug mode.

public static Exception
{

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

Or even better...

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

Then in your code replace Console.WriteLine( ex.ToString() ) to ex.Log();

However, in general the exception itself will be more of a performance issue than dumping to the console.

Answer 5

In C# there is cost which is not insignificant when catching an exception. Test it for yourself, write something like this:

• Create a list of strings
• In this list, make 25% of them a number and the rest a single letter.
• Run a for loop going through each list and doing a int foo = (int)myList[0] but wrap it in try/catch.

Bump up the rate to 50%, then 75%, then 100%. The 100% will be slightly slower, but not by much.

In this particular example, the real world answer would be to use Int32.TryParse instead, but this shows you the penalty.

Answer 6

To avoid getting the warning: "The variable 'ex' is declared but never used" in a catch statement, and also to see the information associated with the exception, do the following:

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

Set a break point inside the exception and look at the debugger variable $exception in either the quick watch window, locals window, or watch window inside Visual Studio (2008).