.net Exception catch block

问题:

What's the difference between the following catch blocks?

try
{
    ...
}
catch
{
    ...
}

and

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

I realize, in either case, the exception instance is not available but is there anything that I can do with one that is not possible with the other?

回答1:

They are almost the same.

From the C# Language Specification, section 8.10:

Some programming languages may support exceptions that are not representable as an object derived from System.Exception, although such exceptions could never be generated by C# code. A general catch clause may be used to catch such exceptions. Thus, a general catch clause is semantically different from one that specifies the type System.Exception, in that the former may also catch exceptions from other languages.

Note that while C# differentiates between the two, they are effectively the same as of .NET 2.0, as noted by this blog:

Thanks to a recent change in the 2.0 CLR, if you had code that decided to throw, say, an int (System.Int32) somewhere, the CLR will now wrap it with a RuntimeWrappedException, and the compiler has been updated to give you that warning that the second clause above is now dead code

warning CS1058: A previous catch clause already catches all exceptions. All non-exceptions thrown will be wrapped in a System.Runtime.CompilerServices.RuntimeWrappedException

For how the CLR knows to do this action for your assembly, you'll notice the compiler now adds a RuntimeCompatibilityAttribute to your assemblies telling it to:
.custom instance void [mscorlib]System.Runtime.CompilerServices.RuntimeCompatibilityAttribute::.ctor() = {property bool 'WrapNonExceptionThrows' = bool(true)}

回答2:

catch without arguments will catch non CLS-compliant exceptions, unlike catch (Exception).

回答3:

From Why catch(Exception)/empty catch is bad

Empty catch statements can be just as bad, depending on the MSIL code that your language generates. C# turns an empty catch statement into catch(System.Object) which means you end up catching all exceptions - even non-CLS compliant exceptions. VB is better-behaved, turning an empty catch statement into catch e as System.Exception which limits you to catching CLS compliant exceptions.

回答4:

If you look at the generated IL here's the difference:

catch(Exception){}:

catch [mscorlib]System.Exception
{}

and just plain catch:

catch{}:

catch [mscorlib]System.Object
{}

So in theory, if you create a language that can have exceptions NOT inherit from System.Exception, there would be a difference...

回答5:

Non-CLS adhering languages (like C++/CLI) can throw objects not derived from System.Exception class. The first code sample will allow you to execute code in the catch block, though you can't examine the thrown object itself. This is almost never an issue, but it could be.

回答6:

I don't believe there is a difference, and a tool like Resharper would tell you that the catch(Exception) is redundant in the second instance, UNLESS you also inserted other catch(SomeSubclassException) exception handling blocks before Exception to apply different exception handling logic for other exception conditions.