Pergunta

Eu tenho o seguinte API:

public interface MyApi {

   /**
    * Performs some stuff.
    * @throws MyException if condition C1
    */
   public void method() throws MyException;
}

Agora estou realizando a seguinte modificação na minha implementação API

public class MyApiImpl {

   public void method() throws MyException {
     if (C1) {
       throw new MyException("c1 message");
     }
     ...
   }
}

é substituída por:

public class MyApiImpl {

   public void method() throws MyException {
     if (C1) {
        throw new MyException("c1 message");
     } else if (c2) {
        throw new MyException("c2 message");
     }
     ...
   }
}

Você considera isso como uma quebra API?

código do cliente ainda irá compilar mas contrato método definido pelo javadoc API não mais é respeitado desde MyExcepiton é jogado por uma condição de "novo".

Se apenas meu arquivo jar API é atualizado, a aplicação clientes vão ainda trabalho, mas, dependendo da forma como os clientes capturar a exceção do comportamento do aplicativo pode mudar muito.

Qual é o seu ponto de vista sobre isso?

Foi útil?

Solução

Sim, você está quebrando o contrato da interface lançando uma exceção quando C1 não ocorre.

Como regra geral, o mais vago o contrato de interface, mais fácil não é para quebrar :) Se a interface não é definido em termos de um C1 explícito, mas em termos mais gerais, que lhe dá muito mais flexibilidade .

Outras dicas

Meu ponto de vista é que você não deve alterar o contrato definido pela API na documentação. Se você precisar de um novo comportamento que você deve quer a.) Criar um novo método que pode ser chamado pelo cliente refletindo esse novo comportamento ou b.) Discutir com o cliente a necessidade para a mudança e torná-los conscientes disso.

Isso pode realmente ir nos dois sentidos, é entre você e seus clientes, como o que sua abordagem será.

Isso depende muito o que c2 é. É dentro dos limites lógicos no contrato pré-existente? Se assim for, você está satisfazendo o contrato por atirar uma MyException. Se não, então talvez você precisa jogar um novo tipo de exceção.

Gostaria de salientar que eu não sou um grande fã de exceções verificadas. Em última instância, forçar alguém a lidar com uma exceção não significa necessariamente fazer o seu código melhor ou mais seguro (na verdade ele pode ter o efeito oposto como eles sloppily pode engolir exceções espúrios).

Eu diria "não", não quebra API, a menos que MyException é uma RuntimeException. Então é.

De qualquer forma, eu subclasse MyException para a condição C2

E ambas as condições C1 e C2 deve ser "excepcional" IMHO, eu não iria fazer um hábito de jogar exceções

É uma ruptura. Se a API é aplicada por construções de linguagem ou simplesmente documentado é irrelevante.

Se esta ruptura provoca um problema para o código do cliente é uma questão diferente. Pode ser que você está corrigindo um defeito e necessidade de caso da tampa C2 desta forma de corrigi-lo. A partir desse cliente respeito desenvolvedores de código pode ser feliz que você fez esta mudança (assumindo que eles não estão actualmente a trabalhar em todo o defeito de tal forma que iria quebrar em face da mudança!)

Eu acho que o problema aqui é que você fez parte de sua interface, condições de aplicação específicas. Se a condição de "C1" eram apenas parte de sua implementação, em seguida, você poderia simplesmente ter criado uma nova implementação que lança uma exceção em "C1" ou "C2" sem quebrar a interface.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top