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"

Unbound

Answer 1

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.

Cuttlefish

Answer 2

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.

Weinstock

Oooh, very nice -- I didn't know about this. +1. – Passim

Answer 3

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.

Keesee

Answer 4

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?

Revet

MessageBox.Show( ex.ToString() ) is a poor way of informing the user that an error has occurred. The message often takes up more than a full screens worth of information and hides any OK button. The exception should be logged but shouldn't every really be shown to the user. – Weinstock

True, but no one suggested MessageBox.Show( ex.ToString() ). – Mam

I think you missed the "Console.WriteLine to prevent a lot of warning of unused ex variable." ... agree with you this is not the right question to be asking. – Cuttlefish

btw, I think I got the question title wrong, will change it. Also, I already do not plan to get the log cause I already have logging mechanism in the Host side of the web service, so logging this in the client would be redundant. Although it might be easier to find. Also I really intend to just show a generic string message that the web service cannot be accessed. – Unbound

Logging on the client is not redundant because the exception might not occur on the server. It could be a client-side networking issue, for instance. Also, please stop thinking that an exception while calling the service means the service is not available. The service may simply be returning a SOAP Fault. This would mean it's available, but somethings wrong with the call you just made. – Revet

Answer 5

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).

Whang

+1 I did not know about $exception. That's really useful to know. – Lacasse

Answer 6

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.

Passim