Using catch without arguments

Question

What is the difference between:

catch
{
    MessageBox.Show(\"Error.\");
}

and:

catch (Exception ex)
{
    MessageBox.Show(         


        

Answer 1

Some exception can not be catch(Exception) catched.

Below excecption in mono on linux, should catch without parameter.

Otherwise runtime will ignore catch(Exception) statment.

System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.

If you encounter the problem like that, try remove parameter of catch statement, log the context vars to find out error cause.

P.S. I don't know how on windows, the program run in windows is normal.

Answer 2

Generally you should catch specific errors first.

But if you go for catching a general Exception like you do I'd say use the second case:

catch (Exception ex)
{
     MessageBox.Show("Error.");
     //we never use ex, so is it better to use catch without arguments?
}

this can help you with debbuging since the variable contains the stack trace, exception message...etc. Which you can use for logging the error or something that will help you preventing it.

Be very carefull using this approach, though:

MessageBox.Show("Error.");

Not keeping track of your errors somewhere(like a log file) can cause a really big mess.

Answer 3

In your second example you can reference exception data, like the stack trace, source, etc. It also gives a general message that is sometimes helpful. It tells you WHY you suffered an exception which is important when debugging.

Answer 4

I think they are the same. But the second case raised a compiler warning because you declare an exception you didn't use. I rather like the first one because you say explicitly that you don't use the exception. There is also a third one

catch (Exception)
{
    //do something
}

if you want to specify the type of exception but doesn't care about the exception itself.

Answer 5

As of .NET 2, if you don't tweak the configuration? Nothing.

Before then, or with some config tweak I can't remember precisely, there was the possibility of an exception being thrown from unmanaged code which didn't get converted into an Exception-compatible object.

Note that there's another option in between, where you specify the type but no variable:

catch (Exception)
{
   ...
}

Personally I'd be very wary of catching an exception without even logging it. It may be required if you're calling a boneheaded API, but it's generally best avoided.