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