Why does C# allow you to 'throw null'?
Because the language specification expects an expression of type System.Exception
there (therefore, null
is a valid in that context) and doesn't restrict this expression to be non-null. In general, there's no way it could detect whether the value of that expression is null
or not. It would have to solve the halting problem. The runtime will have to deal with the null
case anyway. See:
Exception ex = null;
if (conditionThatDependsOnSomeInput)
ex = new Exception();
throw ex;
They could, of course, make the specific case of throwing the null
literal invalid but that wouldn't help much, so why waste specification space and reduce consistency for little benefit?
Disclaimer (before I get slapped by Eric Lippert): This is my own speculation about the reasoning behind this design decision. Of course, I haven't been in the design meeting ;)
The answer to your second question, whether an expression variable caught within a catch clause can ever be null: While the C# specification is silent about whether other languages can cause a null
exception to be propagated, it does define the way exceptions are propagated:
The catch clauses, if any, are examined in order of appearance to locate a suitable handler for the exception. The first catch clause that specifies the exception type or a base type of the exception type is considered a match. A general catch clause is considered a match for any exception type. [...]
For null
, the bold statement is false. So, while purely based on what the C# spec says, we can't say the underlying runtime won't ever throw null, we can be sure that even if that's the case, it'll be only handled by the generic catch {}
clause.
For C# implementations on the CLI, we can refer to the ECMA 335 specification. That document defines all exceptions that the CLI throws internally (none of which are null
) and mentions that user defined exception objects are thrown by the throw
instruction. The description for that instruction is virtually identical to C# throw
statement (except that it doesn't restrict the type of the object to System.Exception
):
Description:
The
throw
instruction throws the exception object (typeO
) on the stack and empties the stack. For details of the exception mechanism, see Partition I.
[Note: While the CLI permits any object to be thrown, the CLS describes a specific exception class that shall be used for language interoperability. end note]Exceptions:
System.NullReferenceException
is thrown ifobj
isnull
.Correctness:
Correct CIL ensures that object is always either
null
or an object reference (i.e., of typeO
).
I believe these are sufficient to conclude caught exceptions are never null
.
Apparently, you can throw null, but it is still turned into an exception somewhere.
Attempting to throw a null
object results in a (completely unrelated) Null Reference Exception.
Asking why you're allowed to throw null
is like asking why you're allowed to do this:
object o = null;
o.ToString();
Taken from here:
If you use this expression in your C# code it will throw a NullReferenceException. That is because the throw-statement needs an object of type Exception as its single parameter. But this very object is null in my example.