Dlaczego nie mamy rzucać tych wyjątków?

Podejrzewam, że intencją ostatnich 2 jest uniknięcie pomyłek z wbudowanymi wyjątkami, które mają oczekiwane znaczenie. Jednak jestem zdania, że jeśli zachowujesz dokładną intencję wyjątku : jest to poprawne do throw. Na przykład, jeśli piszesz kolekcję niestandardową, wydaje się całkowicie rozsądne użycie IndexOutOfRangeException - jaśniejsze i bardziej szczegółowe, IMO, niż ArgumentOutOfRangeException. I chociaż List<T> może wybrać to drugie, jest co najmniej 41 miejsc (dzięki uprzejmości reflector) w BCL (nie wliczając tablic), które rzucają IndexOutOfRangeException- żadna z nich nie jest na tyle "niski poziom", aby zasługiwać na specjalne wyłączenie. Więc tak, myślę, że można słusznie argumentować, że wytyczne są głupie. Podobnie, NullReferenceException jest trochę przydatny w metodach rozszerzeń - jeśli chcesz zachować semantyczny, który:

obj.SomeMethod(); // this is actually an extension method

Rzuca NullReferenceException Gdy obj jest null.

Jak zauważyłeś, w artykule Tworzenie i wyrzucanie wyjątków (C# Programming Guide) w temacie rzeczy, których należy unikać podczas wyrzucania WYJĄTKÓW, Microsoft rzeczywiście wymienia System.IndexOutOfRangeException jako typ wyjątków, które nie powinny być celowo wyrzucane z twojego własnego kodu źródłowego.

static int GetNumber(int index)
{
    int[] nums = { 300, 600, 900 };
    if (index > nums.Length)
    {
        throw new IndexOutOfRangeException();
    }
    return nums[index];
}

Więc sam Microsoft nie jest konsekwentny, ponieważ demonstruje rzucanie IndexOutOfRangeException w swojej dokumentacji dla throw!

To prowadzi mnie do przekonania, że przynajmniej w przypadku IndexOutOfRangeException, mogą być sytuacje, w których ten typ wyjątku can być rzucane przez programistę i być uważane za akceptowalną praktykę.

Kiedy przeczytałem twoje pytanie, zadałem sobie pytanie, na jakich warunkach chce się rzucać typy WYJĄTKÓW NullReferenceException, InvalidCastException lub ArgumentOutOfRangeException.

Moim zdaniem, napotykając jeden z tych wyjątków, ja (deweloper) odczuwam zaniepokojenie ostrzeżeniem w tym sensie, że kompilator do mnie mówi. Tak więc pozwolenie Ci (deweloperowi) na rzucanie takich typów wyjątków jest równoważne (kompilatorowi) sprzedaniu odpowiedzialności. Na przykład, sugeruje to, że kompilator powinien teraz zezwolić na programista decyduje, czy obiekt jest null. Ale dokonywanie takiej determinacji naprawdę powinno być zadaniem kompilatora.

PS: od 2003 roku rozwijam własne wyjątki, więc mogę je rzucać, jak chcę. Uważam to za najlepszą praktykę.