pré-condições e exceções

Question

Suponha que você tenha um método com alguns pré e pós-condições. É ok para criar uma classe de exceção para cada pré-condição que não é realizado? Por exemplo: Não realizar meios PRE1 jogando um exemplo notPre1Exception.

Answer 1

Sim e não.

Sim - Violar uma pré-condição é certamente um momento oportuno para lançar uma exceção. Jogando um mais exceção específica fará pegar essa exceção específica simples.

Não - Declarando uma nova classe de exceção para cada condição em seu programa / api parece maneira exagero. Isso poderia resultar em centenas ou milhares de exceções eventualmente. Isto parece um desperdício tanto mentalmente e computacionalmente.

Eu recomendaria exceções jogando por violações pré-condição. Eu não, no entanto, recomendamos a definição de uma nova exceção para cada condição. Em vez disso, eu recomendo a criação de classes mais amplas de exceções que cobrem uma específica tipo de condição prévia violação, em vez de uma violação específica condição. (Eu também recomendo o uso de exceções existentes onde eles se encaixam bem.)

Answer 2

Por que não deseja definir PreconditionFailedException (string pré-condição)? Jogando um tipo de exceção diferente para cada condição não é um exagero.

Answer 3

Uma pré-condição falhou deve lançar uma AssertException, ou algo similar. Antes de chamar um método, é pré-condição deve manter. Se o chamador não fazer esta verificação, é um erro no programa, ou de uma utilização incorrecta do método (API).

Answer 4

Só se não realizar as pré-condições seria uma rara excepcional ocorrência.

Answer 5

Parece um uso útil de exceções para mim. Certamente permite mais o registo de grão fino e depuração do que apenas uma geral 'pré-condição falhou', embora você também pode ter um único 'pré-condições falhou' exceção e colocar o que pré-condições falharam na mensagem de exceção.

Answer 6

Eu acho que é ok para criar uma exceção diferente para todas as suas exceções, desde que você planeja usar e lidar com eles.

Eu descobri que a melhor o erro / exceção manipulação mais fácil é para depurar software nas fases posteriores.

Por exemplo: Se você tem um excpeiton genérico para lidar com todas as entradas ruim, então você deve olhar para tudo o que foi passado para o método se houver um erro. Se você tem um excpetion de todos os tipos de más condições você vai saber exaclty onde olhar.

Answer 7

Parece possível para mim, mas se você quiser continuar esta forma de lidar com condições prévias, você vai acabar com N classes de exceção por método de classe. Parece um crescimento explosivo das classes 'não funcionais'.

Eu sempre gostei de código onde a funcionalidade 'core' não lidar com violação das pré-condições (além de afirmar-las - uma grande ajuda). Este código pode ser envolvida em um 'pré-condição-checker', o que faz exceções lançar ou notifica não-satisfação de outra forma.

Answer 8

Como uma forma muito geral para determinar se você nunca deve criar uma classe ou não (e uma exceção é uma classe), você deve determinar se há algum código que faz com que esta classe única de todas as outras classes (neste caso exceções).

Se não, eu tinha acabado de definir a seqüência na exceção e chamá-lo um dia. Se você está executando o código em sua exceção (talvez um mecanismo de recuperação genérica que pode lidar com várias situações chamando exception.resolve () ou algo assim), então ele pode ser útil.

Eu percebo que as exceções nem sempre seguem esta regra, mas eu acho que é mais ou menos porque excepções previstas pela linguagem pode não ter qualquer lógica de negócios neles (porque eles não sabem o negócio - bibliotecas sempre tendem a ser cheio de exceções às regras OO)

Answer 9

Eu acho que Ben está no alvo aqui. Qual é o ponto em jogar diferentes exceções, se você não está indo para alcançá-los? Se você realmente quer jogar um diferente eu teria pelo menos um "PreconditionFailedException" classe base comum que todos derivam de, e tentar organizá-los em algum tipo de heirachy para que você possa pegar grupos deles. Personlly, eu não teria diferentes e só tem uma exceção comum que você jogue com os detalhes da falha em cada um.

Answer 10

Não você não deve criar uma exceção específica para cada condição, porque vai contra os princípios do Design-by-Contract.

Os corolários de condições de aplicação é que eles devem fazer parte da documentação e que você deve fornecer os métodos necessários para o chamador para verificar se todos os pré-requisitos são válidos. (Isto é, se um método de execução está a contar com o status de um objecto, o método para verificar o estado deve estar disponível para o chamador).

Assim, o chamador deve ser capaz de verificar se todos os pré-requisitos sejam cumpridos antes de chamar o método.

exceções específicas de execução para cada pré-condição violados iria / poderia incentivar o chamador para usar o padrão de try / catch em torno da chamada de método, o que está em contradição com a filosofia do Design-by-Contract.

Answer 11

Eu diria que está tudo bem, contanto que você fazê-los exceções não verificadas (subclasse de RuntimeException em Java). No entanto, em Java é melhor apenas afirmações de uso.

Answer 12

Se você fizer isso, certifique-se que todos eles herdar de outra exceção costume comum.