Exceções "Erro de programação" - Minha abordagem é sólida?

Atualmente, estou tentando melhorar meu uso de exceções e encontrei a importante distinção entre exceções que significam erros de programação (por exemplo, alguém passou nulo como argumento ou chamou um método em um objeto depois que ele foi descartado) e aqueles que significam uma falha no operação que não é culpa do chamador (por exemplo, uma exceção de E / S).

Como esses dois tipos de exceções devem ser tratados de maneira diferente? Você acha que as exceções de erro precisam ser explicitamente documentadas ou é suficiente para documentar as pré-condições relevantes? E você pode deixar de fora a documentação de uma exceção de pré-condição ou erro, se for óbvio (por exemplo, ObjectDisposedExceptionao chamar um método em um objeto descartado)

Eu acho que você está no caminho certo. Nem jogar, capturar nem documentar todas as exceções potencialmente lançáveis ​​faz muito sentido. Há momentos em que o rigor do produto exige um alto grau de emprego e documentação de exceção (por exemplo, certos aspectos críticos de segurança de um sistema).

A estratégia de ser mais defensivo, usando conceitos de contrato para identificar condições prévias (e pós-condições) em chamadores especialmente a jusante (por exemplo, qualquer coisa que se assemelhe a um membro público ou protegido) será frequentemente mais eficaz e mais flexível. Isso se aplica não apenas à implementação, mas à documentação. Se os desenvolvedores souberem o que é esperado, é mais provável que eles sigam as regras e menos propensos a confundir ou abusar do código que você escreveu.

Algumas das coisas comuns que devem ser documentadas incluem o caso de parâmetros nulos. Muitas vezes, há uma consequência para o uso deles que leva o resultado a algo que normalmente não seria esperado, mas que é permitido e usado por várias razões, às vezes por flexibilidade. Como consumidor de um membro que possui parâmetros que permitem valores nulos ou outros valores não racionais especiais (como tempo negativo ou quantidades negativas), espero vê-los identificados e explicados.

Para parâmetros não nulos, como consumidor de um membro público ou protegido, quero saber que nulo não é permitido. Quero saber qual é o intervalo válido de valores no contexto fornecido. Quero saber as conseqüências do uso de valores que estão fora do intervalo normal, mas que são válidos em um contexto de chamada diferente (por exemplo, o valor do tipo geralmente é válido para qualquer operação, mas não aqui - como um parâmetro booleano que não espere falso como um valor válido.

No que diz respeito à plataforma ou às interfaces bem conhecidas, não acho que você precise ir ao extremo ao documentá-lo. No entanto, como você tem a oportunidade, como desenvolvedor, de variar a implementação de qualquer orientação da plataforma, observe como isso pode ser útil.

Específicas para IDisposable, as implementações dessa interface geralmente oferecem um método alternativo preferido ao processo de descarte explícito. Nesses casos, destaque o método preferido e observe que a eliminação explícita não é preferida.

Aqui estão meus próprios pensamentos. Observe que não tenho muita certeza de que esse é o melhor caminho a seguir, e foi por isso que criei essa pergunta em primeiro lugar.

Tanto quanto eu entendo, faz pouco sentido para um chamador imediato realmente lidar com exceções de erro de programação, ele deve garantir que as pré-condições sejam atendidas. Somente os manipuladores de exceção "externos" nos limites da tarefa devem capturá-los, para que possam manter o sistema em execução se uma tarefa falhar.

Para garantir que o código do cliente possa capturar de maneira limpa as exceções de "falha" sem capturar exceções de erro por engano, crio minhas próprias classes de exceção para todas as exceções de falha agora e as documento nos métodos que as lançam. Eu os faria exceções verificadas em Java.

Até recentemente, eu tentava documentar todas as exceções que um método poderia lançar, mas que às vezes cria uma lista indesejada que precisa ser documentada em todos os métodos da cadeia de chamadas até que você possa mostrar que o erro não ocorrerá. Em vez disso, agora documento as condições prévias nas descrições de resumo / parâmetro e nem mencione o que acontece se elas não forem atendidas. A idéia é que as pessoas não devem tentar capturar essas exceções explicitamente de qualquer maneira, portanto, não há necessidade de documentar seus tipos.

Para documentar as pré-condições, declarar o óbvio apenas cria confusão desnecessária - se passar nulo a um método não faz sentido óbvio, o chamador deve esperar uma exceção se passar nulo de qualquer maneira, mesmo que isso não esteja documentado. O mesmo vale para o caso de ObjectDisposedException - essa interface é tão amplamente usada que alguém que chama Dispose ficaria ciente da responsabilidade de garantir que ninguém continuasse usando o objeto.

Uma regra prática razoável:

1. Pegue qualquer exceção que você possa corrigir.
2. Capte, comente e repita qualquer exceção que você não pode corrigir, mas pode dizer algo útil.
3. Não pegue nenhuma exceção que não possa processar ou diagnosticar melhor do que o processamento padrão.

Você pode querer ter um manipulador de exceção não fatal de nível superior para interceptar qualquer coisa que não possa ser tratada abaixo para tentar impedir que seu aplicativo caia, mas isso dependerá fortemente do seu aplicativo em particular. Por exemplo, os aplicativos iOS preferem interceptar o máximo possível; um aplicativo de linha de comando pode estar perfeitamente bem se não detectar quase nenhuma exceção.

Mesmo Java não "documenta" todas as exceções. Apesar do requisito de que todas as thrown exceções sejam mencionadas em uma throwscláusula, qualquer linha de código pode gerar um RuntimeExceptionsem a necessidade de declará-la na assinatura do método.

A maneira padrão de fazer isso é com a abordagem java. Erros de programação devem ser exceções desmarcadas e não devem ser capturados para garantir uma falha rápida. Erros de contrato são exceções verificadas e devem ser tratadas adequadamente pelo cliente.