Por que não devemos lançar essas exceções?

Me deparei com esta página do MSDN que afirma:

Não lance Exception , SystemException , NullReferenceException ou IndexOutOfRangeException intencionalmente de seu próprio código-fonte.

Infelizmente, não se preocupa em explicar o porquê. Posso adivinhar as razões, mas espero que alguém com mais autoridade no assunto possa oferecer sua visão.

Os dois primeiros fazem algum sentido óbvio, mas os dois últimos parecem aqueles que você gostaria de empregar (e na verdade, eu usei).

Além disso, essas são as únicas exceções que devemos evitar? Se houver outros, quais são e por que também deveriam ser evitados?

Exceptioné o tipo base para todas as exceções e, como tal, terrivelmente inespecífico. Você nunca deve lançar essa exceção porque ela simplesmente não contém nenhuma informação útil. A captura do código de chamada para exceções não pode eliminar a ambigüidade da exceção lançada intencionalmente (de sua lógica) de outras exceções do sistema que são totalmente indesejadas e apontam falhas reais.

O mesmo motivo também se aplica a SystemException. Se você olhar a lista de tipos derivados, poderá ver um grande número de outras exceções com semânticas muito diferentes.

NullReferenceExceptione IndexOutOfRangeExceptionsão de um tipo diferente. Essas são exceções muito específicas, portanto, pode ser bom jogá-las . No entanto, você ainda não vai querer jogá-los, pois eles geralmente significam que existem alguns erros reais em sua lógica. Por exemplo, a exceção de referência nula significa que você está tentando acessar um membro de um objeto que é null. Se isso for uma possibilidade em seu código, você deve sempre verificar explicitamente nulle lançar uma exceção mais útil (por exemplo ArgumentNullException). Da mesma forma, IndexOutOfRangeExceptions ocorrem quando você acessa um índice inválido (em matrizes - não em listas). Você deve sempre certificar-se de não fazer isso em primeiro lugar e verificar os limites de, por exemplo, um array primeiro.

Existem algumas outras exceções como essas duas, por exemplo InvalidCastExceptionou DivideByZeroException, que são lançadas para falhas específicas em seu código e geralmente significam que você está fazendo algo errado ou não está verificando alguns valores inválidos primeiro. Ao descartá-los conscientemente de seu código, você está apenas tornando mais difícil para o código de chamada determinar se eles foram lançados devido a alguma falha no código ou apenas porque você decidiu reutilizá-los para algo em sua implementação.

Claro, existem algumas exceções (hah) a essas regras. Se você estiver construindo algo que pode causar uma exceção que corresponda exatamente a uma existente, sinta-se à vontade para usar isso, especialmente se estiver tentando corresponder a algum comportamento integrado. Apenas certifique-se de escolher um tipo de exceção muito específico.

Em geral, porém, a menos que você encontre uma exceção (específica) que preencha sua necessidade, você deve sempre considerar a criação de seus próprios tipos de exceção para exceções esperadas específicas. Especialmente quando você está escrevendo código de biblioteca, isso pode ser muito útil para separar as fontes de exceção.

Suspeito que a intenção com os 2 últimos é evitar confusão com exceções embutidas que têm um significado esperado. No entanto, sou da opinião que, se você está preservando a intenção exata da exceção : é a correta para throw. Por exemplo, se você estiver escrevendo uma coleção personalizada, parece totalmente razoável usar IndexOutOfRangeException- mais claro e mais específico, IMO, do que ArgumentOutOfRangeException. E embora você List<T>possa escolher o último, há pelo menos 41 lugares (cortesia do refletor) no BCL (sem incluir matrizes) que são projetadas sob medida IndexOutOfRangeException- nenhum dos quais é de "nível baixo" o suficiente para merecer isenção especial. Então, sim, acho que você pode argumentar com justiça que essa diretriz é boba. Da mesma forma,NullReferenceException é bastante útil em métodos de extensão - se você deseja preservar a semântica que:

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

joga um NullReferenceExceptionquando objé null.

Como você assinalou, no artigo Criando e lançando exceções (Guia de programação C #) sob o tópico Coisas a serem evitadas ao lançar exceções , a Microsoft realmente lista System.IndexOutOfRangeExceptioncomo um tipo de exceção que não deve ser lançado intencionalmente de seu próprio código-fonte.

Em contraste, no entanto, no lançamento do artigo (Referência C #) , a Microsoft parece violar suas próprias diretrizes. Aqui está um método que a Microsoft incluiu em seu exemplo:

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

Portanto, a própria Microsoft não está sendo consistente ao demonstrar o lançamento de IndexOutOfRangeExceptionem sua documentação para throw!

Isso me leva a acreditar que, pelo menos para o caso de IndexOutOfRangeException, pode haver ocasiões em que esse tipo de exceção pode ser lançado pelo programador e considerado uma prática aceitável.

Quando li sua pergunta, me perguntei em que condições alguém gostaria de lançar os tipos de exceção NullReferenceException , InvalidCastExceptionou ArgumentOutOfRangeException.

Na minha opinião, ao encontrar um desses tipos de exceção, eu (o desenvolvedor) fico preocupado com o aviso no sentido de que o compilador está falando comigo. Portanto, permitir que você (o desenvolvedor) lance tais tipos de exceção é equivalente a (o compilador) vender a responsabilidade. Por exemplo, isso sugere que o compilador deve agora permitir que o desenvolvedor decida se um objeto é null. Mas fazer essa determinação deve ser realmente trabalho do compilador.

PS: Desde 2003, venho desenvolvendo minhas próprias exceções para poder lançá-las como quiser. Eu acho que é considerada uma prática recomendada fazer isso.

Colocando a discussão sobre NullReferenceExceptione de IndexOutOfBoundsExceptionlado:

Que tal pegar e jogar System.Exception. Eu lancei muito esse tipo de exceção no meu código e nunca me incomodei com isso. Da mesma forma, muitas vezes eu pego o não específicoException tipo , e também funcionou muito bem para mim. Então, por que isso?

Normalmente, os usuários argumentam que devem ser capazes de distinguir as causas dos erros. Pela minha experiência, existem apenas algumas situações em que você deseja lidar com diferentes tipos de exceção de maneira diferente. Para aqueles casos, onde você espera que os usuários tratem os erros programaticamente, você deve lançar um tipo de exceção mais específico. Para outros casos, não estou convencido pela diretriz geral de melhores práticas.

Portanto, em relação ao lançamento Exception, não vejo razão para proibir em todos os casos.

EDITAR: também na página MSDN:

As exceções não devem ser usadas para alterar o fluxo de um programa como parte da execução normal. As exceções devem ser usadas apenas para relatar e tratar condições de erro.

Exagerar cláusulas catch com lógica individual para diferentes tipos de exceção também não é uma prática recomendada.