Is an empty catch the same as "catch Exception" in a try-catch statement?

try {
}
catch (Exception) {
}

can I just write

try {
}
catch {
}

Is this ok in C开发者_JAVA百科# .NET 3.5? The code looks nicer, but I don't know if it's the same.

They are not the same.

catch (Exception) { } will catch managed exceptions only; catch { } will catch non-CLS exceptions as well: http://msdn.microsoft.com/en-gb/bb264489.aspx

An unhandled non-CLS compliant exception becomes a security issue when previously allowed permissions are removed in the catch block. Because non-CLS compliant exceptions are not caught, a malicious method that throws a non-CLS compliant exception could run with elevated permissions.

Edit: Turns out .NET 2.0+ wraps the values -- so they are the same. That's a bit of a relief!

Yes, the advantage of the first form is that you can name the exception variable and then use the object to log the exception details to file, etc...

try {
}
catch (Exception ex) {
  // Log exception message here...
}

Also, it is generally a bad practice to catch the generic Exception class if you can instead catch specific exceptions (such as an IOException) using the first form.

Edit: As of C# 2.0, non-CLS-compliant exceptions can be caught in both ways.

So, yes. They are identical. A parameter-less catch clause without a Type declaration catches all Exceptions.

In the CLR 2.0, MS introduced RuntimeWrappedException, which is a CLS-compliant exception type, to encapsulate non-CLS-compliant exceptions. The C# compiler still doesn't allow you to throw them, but it can catch them with the catch (Exception) { } syntax.

This is why the C# compiler will issue warning CS1058 if you use both clauses at the same time on CLR 2.0 or later.

Thus, they are in fact identical.

Its the same, but if you put an e after Exception in your first example then you know what exception was thrown...

edit: you should never catch exception, how do you know how to handle it properly?

They are different as noted:

An unhandled non-CLS compliant exception becomes a security issue when previously allowed permissions are removed in the catch block. Because non-CLS compliant exceptions are not caught, a malicious method that throws a non-CLS compliant exception could run with elevated permissions.

You can see the difference in the IL generated:

//no (Exception)
.try L_0001 to L_0005 catch object handler L_0005 to L_000a

//with (Exception)
.try L_0001 to L_0005 catch [mscorlib]System.Exception handler L_0005 to L_000a

I guess unless you want to use the Exception in some sort, the second one is perfectly fine, though in order to use the exception in the first one, you need to declare a variable like this:

try {
}
catch (Exception e) {
    //do something with e
}

Both of your examples appear like you're not doing anything with the exception data. This is generally not a good practice. But both are exactly the same since all exceptions classes are derived from System.Exception.

You should consider doing some type of logging then possibly rethrow the original exception or wrap it in a more specialized exception that your application can understand.

try
{
    // Some code here
}
catch(Exception ex)
{
    // Do some logging
    throw;
}

OR

try
{
    // Some code here
}
catch(Exception ex)
{
    // Do some logging
    // wrap your exception in some custom exception
    throw new CustomException("Some custom error message, ex); 
}

You should typically only catch exceptions that your code could handle, otherwise it should bubble up and it should eventually be caught by a global exception handler assuming you have one.

Parameter less constructor will cause handling of exception types coming from some other languages, exception which are not inherited from c# SYSTEM.EXCEPTION class.