Interruzione dell'API Java

Question

Ho la seguente API:

public interface MyApi {

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

Ora sto eseguendo la seguente modifica nella mia implementazione API

public class MyApiImpl {

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

è sostituito da:

public class MyApiImpl {

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

Lo consideri una rottura dell'API?

Il codice client verrà comunque compilato ma il contratto del metodo definito dall'API javadoc non viene più rispettato poiché MyExcepiton viene generato da un "nuovo" condizioni.

Se viene aggiornato solo il mio file jar API, l'applicazione client funzionerà comunque, ma a seconda del modo in cui i client rilevano l'eccezione, il comportamento dell'applicazione può cambiare molto.

Qual è il tuo punto di vista al riguardo?

Answer 1

Sì, stai rompendo il contratto dell'interfaccia generando un'eccezione quando C1 non si verifica.

Come regola generale, più vago è il contratto di interfaccia, più facile non si romperà :) Se l'interfaccia non è definita in termini di un C1 esplicito, ma in termini più generali, ciò offre molta più flessibilità .

Answer 2

Il mio punto di vista è che non dovresti cambiare il contratto definito dall'API nella documentazione. Se hai bisogno di un nuovo comportamento, dovresti a.) Creare un nuovo metodo che può essere chiamato dal client in base a questo nuovo comportamento oppure b.) Discutere con il cliente la necessità del cambiamento e renderlo consapevole.

Questo può davvero andare in entrambi i modi, è tra te e i tuoi clienti su quale sarà il tuo approccio.

Answer 3

Dipende in gran parte da cosa è C2. È entro i limiti logici del contratto preesistente? In tal caso, stai soddisfacendo il contratto lanciando MyException. In caso contrario, forse devi lanciare un nuovo tipo di eccezione.

Devo sottolineare che non sono un grande fan delle eccezioni verificate. In definitiva, forzare qualcuno a gestire un'eccezione non rende necessariamente il suo codice migliore o più sicuro (in effetti può avere l'effetto opposto in quanto può inghiottire sciatto eccezioni spurie).

Answer 4

Direi "no", nessuna rottura dell'API, a meno che MyException non sia una RuntimeException. Quindi lo è.

Ad ogni modo, vorrei sottoclassare MyException per la condizione C2

E entrambe le condizioni C1 e C2 dovrebbero essere "eccezionali". IMHO, non prenderei l'abitudine di gettare eccezioni

Answer 5

È una rottura. Non importa se l'API è applicata da costrutti di linguaggio o semplicemente documentata.

Se questa rottura provoca un problema per il codice client è una domanda diversa. È possibile che si stia risolvendo un difetto e che sia necessario coprire il caso C2 in questo modo per risolverlo. Da questo punto di vista, gli sviluppatori di codici client potrebbero essere contenti di aver apportato questa modifica (supponendo che al momento non stiano aggirando il difetto in modo tale da rompersi di fronte alla modifica!)

Answer 6

Penso che il problema qui sia che hai fatto parte della tua interfaccia, condizioni specifiche di implementazione. Se la "C1" le condizioni erano solo una parte della tua implementazione, quindi avresti potuto semplicemente creare una nuova implementazione che genera un'eccezione su " C1 " o "C2" senza interrompere l'interfaccia.