Why must a type thrown or caught derive from System.Exception

Question

So just out of curiosity I wanted to see what was special about the exception class that allowed it to be used with the keyword Throw while a standard class is not.

All I found is that the Exception class implemented the following

public class Exception : System.Object, System.Runtime.Serialization.ISerializable, System.Runtime.InteropServices._Exception { } 

So I tried implementing those same interfaces and attempting to throw my own custom exception that did not derive from System.Exception to no avail. I was simply advised that

The type caught or thrown must be derived from System.Exception

So is there any specific reason for this? I assume there is as few choices in managed languages seem to be arbitrary.

Answer 1

I think your premise is mistaken. It is possible that an object is thrown that is not derived from System.Exception. You just can't throw it in C# or examine the object in a catch clause. From section 8.10 of the C# spec (v4.0):

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.

An example of a general catch:

try { } catch (Exception) { } // 'specific' catch catch { } // 'general' catch 

In particular, this is important when calling unmanaged code.

Some types always seem to get special treatment in every language. Mostly because they are so fundamental to the system. System.Exception, System.ValueType, System.Delegate are all special types in C# that are tightly bound to language keywords and the CLR, so it is not surprising that you can't just implement classes that take over their roles.