C＃で「nullをスロー」できるのはなぜですか？

Question 1

特に複雑な例外処理コードを書いているときに、誰かが尋ねました。例外オブジェクトがnullでないことを確認する必要はありませんか？もちろんそうではないと言いましたが、試してみることにしました。どうやら、nullをスローすることはできますが、それでもどこかで例外になります。

なぜこれが許可されるのですか？

throw null;

このスニペットでは、ありがたいことに「ex」はnullではありませんが、nullになる可能性はありますか？

try
{
  throw null;
}
catch (Exception ex)
{
  //can ex ever be null?

  //thankfully, it isn't null, but is
  //ex is System.NullReferenceException
}

Question 2

言語仕様はSystem.Exceptionそこで型の式を期待し（したがって、nullそのコンテキストで有効です）、この式がnull以外になることを制限しないためです。一般に、その式の値がそうであるかどうかを検出する方法はありnullません。停止性問題を解決する必要があります。nullとにかく、ランタイムはケースに対処する必要があります。見る：

Exception ex = null;
if (conditionThatDependsOnSomeInput) 
    ex = new Exception();
throw ex;

もちろん、nullリテラルをスローする特定のケースを無効にすることはできますが、それはあまり役に立ちません。それでは、なぜ仕様スペースを無駄にし、一貫性を減らしてほとんど利益がないのでしょうか。

_{免責事項（Eric Lippertに叩かれる前）：これは、この設計上の決定の背後にある理由についての私自身の推測です。もちろん、私はデザインミーティングに参加していません;）}

2番目の質問に対する答えは、catch句内でキャッチされた式変数がnullになる可能性があるかどうかです。C＃仕様では、他の言語でnull例外が伝播されるかどうかについては言及されていませんが、例外が伝播される方法は定義されています。

キャッチ句がある場合は、出現順に調べて、例外に適したハンドラーを見つけます。例外タイプまたは例外タイプの基本タイプを指定する最初のcatch句は、一致と見なされます。一般的なcatch句は、すべての例外タイプに一致すると見なされます。[...]

の場合null、太字のステートメントは誤りです。したがって、純粋にC＃仕様の内容に基づいていますが、基になるランタイムがnullをスローしないとは言えませんが、その場合でも、genericcatch {}句によってのみ処理されると確信できます。

CLIでのC＃実装については、ECMA335仕様を参照できます。このドキュメントでは、CLIが内部でスローするすべての例外（いずれもnull）を定義し、ユーザー定義の例外オブジェクトがthrow命令によってスローされることに言及しています。その命令の説明は、C＃throwステートメントと実質的に同じです（オブジェクトのタイプをに制限しないことを除いてSystem.Exception）：

説明：

このthrow命令は、例外オブジェクト（type O）をスタックにスローし、スタックを空にします。例外メカニズムの詳細については、パーティションIを参照してください。
[注：CLIはすべてのオブジェクトのスローを許可しますが、CLSは、言語の相互運用性に使用される特定の例外クラスを記述します。エンドノート]

例外：

System.NullReferenceException場合にスローされてobjいますnull。

正しさ：

正しいCILは、オブジェクトが常にnullまたはオブジェクト参照（つまり、タイプO）であることを保証します。

キャッチされた例外は決してないと結論付けるには、これらで十分だと思いますnull。

Question 3

どうやら、nullをスローすることはできますが、それでもどこかで例外になります。

nullオブジェクトをスローしようとすると、（完全に無関係な）Null参照例外が発生します。

投げるnullことが許可されている理由を尋ねるのは、なぜこれを行うことが許可されているのかを尋ねるようなものです。

object o = null;
o.ToString();

Question 4

ここから撮影：

この式をC＃コードで使用すると、NullReferenceExceptionがスローされます。これは、throwステートメントが単一のパラメーターとしてExceptionタイプのオブジェクトを必要とするためです。しかし、私の例では、このオブジェクト自体がnullです。

Question 5

スローがそれを検出してNullReferenceExceptionに変換するため、C＃でnullをスローすることはできない場合がありますが、nullを受信することは可能です...たまたまそれを受信しているため、キャッチが発生します（ 'ex'がnullになることを期待している）null参照例外が発生すると、アプリが停止します（これが最後のキャッチだったため）。

したがって、C＃からnullをスローすることはできませんが、netherworldはnullをスローできるため、最も外側のcatch（Exception ex）はそれを受け取る準備をする方がよいでしょう。参考までに。

Question 6

おそらくあなたはできないと思います-nullをスローしようとすると、それはできません。そのため、null参照例外をスローするというエラーの場合に必要なことを実行します。したがって、実際にnullをスローしているのではなく、nullをスローできていないため、スローが発生します。

Question 7

「..ありがたいことに 'ex'はnullではありませんが、nullになる可能性はありますか？」と答えようとしています。

間違いなくnullの例外をスローすることはできないため、catch句もnullの例外をキャッチする必要はありません。したがって、exがnullになることはありません。

私は今、この質問が実際にすでに尋ねられているのを見る。

Question 8

例外には、例外がスローされる場所に関する詳細が含まれていることに注意してください。コンストラクターはそれがどこにスローされるかわからないので、throwメソッドがthrowが行われるポイントでそれらの詳細をオブジェクトに注入することは意味があります。つまり、CLRがデータをnullに挿入しようとしているため、NullReferenceExceptionがトリガーされます。

これがまさに起こっていることであるかどうかはわかりませんが、それは現象を説明しています。

これが真であると仮定すると（そして、nullをスローするよりもexをnullにするためのより良い方法は考えられません;）、それはexがnullになる可能性がないことを意味します。

Question 9

古いc＃では：

この構文を検討してください。

public void Add<T> ( T item ) => throw (hashSet.Add ( item ) ? null : new Exception ( "The item already exists" ));

私はそれがこれよりずっと短いと思います：

public void Add<T> ( T item )
{
    if (!hashSet.Add ( item ))
        throw new Exception ( "The item already exists" );
}