.net Exception catch block

Question

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?

Perambulator

Just FYI the exception is available in the debugger via a reference to $exception when you hit the block even if you haven't defined a variable for the exception. – Nose

@Quintin That's very good to know. – Perambulator

Answer 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)}

Attribute

+1 Thanks for the reference! but I'm accepting @Joren 's answer because he was the first to point it out. – Perambulator

Ha! It turns out that Joren and I were wrong afterall -- they are the same now. – Attribute

Answer 2

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

Germanize

Could you provide a reference for this statement? – Croatia

@Ray Hayes: see my answer: https://mcmap.net/q/969437/-net-exception-catch-block/… – Attribute

This is true. Non-CLS compliant exceptions are caught by this notation msdn.microsoft.com/en-gb/bb264489.aspx – Roybal

Is this a feature or a bug? :) From the descriptions it seems like unwanted functionality. But I assume thats because for the majority of users it wouldn't be helpful? – Claudelle

@havok: I guess the purpose of this is so that if you call into a third party library you're not helpless if it happens to throw a non-CLS-compliant exception. – Germanize

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

Inclinable

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

Assemble

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

Kordofan

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

Copyboy