Java API break

Question

J'ai l'API suivante:

public interface MyApi {

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

J'effectue actuellement la modification suivante dans la mise en œuvre de mon API

public class MyApiImpl {

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

est remplacé par:

public class MyApiImpl {

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

Considérez-vous cela comme une casse d'API?

Le code du client sera toujours compilé mais le contrat de méthode défini par l’API javadoc n’est plus respecté, car MyExcepiton est lancé par un "nouveau". condition.

Si seul le fichier jar de mon API est mis à jour, l'application client continuera à fonctionner, mais en fonction de la façon dont les clients détectent l'exception, le comportement de l'application peut changer considérablement.

Quel est votre point de vue à ce sujet?

Answer 1

Oui, vous rompez le contrat de l'interface en générant une exception lorsque C1 ne se produit pas.

En règle générale, plus le contrat d'interface est vague, plus il est facile de ne pas le rompre :) Si l'interface n'est pas définie en termes de C1 explicite, mais en termes plus généraux, cela donne beaucoup plus de flexibilité. .

Answer 2

Mon point de vue est que vous ne devez pas modifier le contrat défini par l'API dans la documentation. Si vous avez besoin d’un nouveau comportement, vous devez: a) créer une nouvelle méthode pouvant être appelée par le client et refléter ce nouveau comportement, ou b.) Discuter avec le client de la nécessité de la modification et le tenir au courant.

Cela peut vraiment aller dans les deux sens, c'est entre vous et vos clients quant à votre approche.

Answer 3

Cela dépend en grande partie de ce que c2 est. Est-ce que c'est dans les limites logiques du contrat préexistant? Si tel est le cas, vous remplissez le contrat en lançant une exception MyException. Sinon, vous devrez peut-être lancer un nouveau type d'exception.

Je dois préciser que je ne suis pas un grand fan des exceptions vérifiées. En fin de compte, forcer une personne à gérer une exception ne rend pas son code meilleur ou plus sûr (en fait, cela peut avoir l’effet opposé puisqu’il peut avaler des exceptions fictives de manière négligée).

Answer 4

Je dirais "non", pas de casse d'API, sauf si MyException est une exception RuntimeException. Alors c’est.

Quoi qu'il en soit, je sous-classe MyException pour la condition C2

Et les deux conditions C1 et C2 doivent être "exceptionnelles". IMHO, je ne prendrais pas l'habitude de lancer des exceptions

Answer 5

C'est une casse. Que l'API soit appliquée par des constructions de langage ou simplement documentée est sans importance.

La question de savoir si cette rupture cause un problème pour le code client est une question différente. Il se peut que vous corrigiez un défaut et que vous deviez couvrir le cas C2 de cette manière. De ce point de vue, les développeurs de code client peuvent être heureux que vous ayez apporté cette modification (en supposant qu’ils ne travaillent actuellement pas autour du défaut de manière à casser le changement!)

Answer 6

Je pense que le problème ici est que vous avez intégré dans votre interface des conditions de mise en œuvre spécifiques. Si le " C1 " Si la condition n’était qu’une partie de votre implémentation, vous auriez pu simplement créer une nouvelle implémentation qui lève une exception sur "C1". ou " C2 " sans casser l'interface.