Ruptura de API Java

Question

Tengo la siguiente API:

public interface MyApi {

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

Ahora estoy realizando la siguiente modificación en mi implementación de API

public class MyApiImpl {

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

se reemplaza por:

public class MyApiImpl {

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

¿Considera esto como una ruptura de la API?

El código del cliente aún se compilará, pero el contrato de método definido por la API javadoc ya no se respetará, ya que MyExcepiton es lanzado por un " nuevo " condición.

Si solo se actualiza mi archivo jar API, la aplicación de los clientes seguirá funcionando, pero dependiendo de la forma en que los clientes capturen la excepción, el comportamiento de la aplicación puede cambiar mucho.

¿Cuál es su punto de vista sobre eso?

Answer 1

Sí, está rompiendo el contrato de la interfaz lanzando una excepción cuando C1 no ocurre.

Como regla general, cuanto más vago es el contrato de interfaz, más fácil es no romper :) Si la interfaz no está definida en términos de un C1 explícito, sino en términos más generales, eso da mucha más flexibilidad .

Answer 2

Mi punto de vista es que no debe cambiar el contrato definido por la API en la documentación. Si necesita un nuevo comportamiento, debe a.) Crear un nuevo método al que pueda llamar el cliente para reflejar este nuevo comportamiento o b.) Discutir con el cliente la necesidad del cambio y hacer que se den cuenta.

Esto realmente puede ir en ambos sentidos, es entre usted y sus clientes en cuanto a cuál será su enfoque.

Answer 3

Depende en gran medida de qué es c2. ¿Está dentro de los límites lógicos del contrato preexistente? Si es así, está cumpliendo el contrato lanzando una MyException. De lo contrario, tal vez deba lanzar un nuevo tipo de excepción.

Debo señalar que no soy un gran admirador de las excepciones comprobadas. En última instancia, obligar a alguien a lidiar con una excepción no necesariamente hace que su código sea mejor o más seguro (de hecho, puede tener el efecto contrario, ya que pueden tragar descuidadamente excepciones espurias).

Answer 4

Yo diría '' no '', sin rotura de API, a menos que MyException sea una RuntimeException. Entonces lo es.

De todos modos, subclase MyException para la condición C2

Y ambas condiciones C1 y C2 deben ser "excepcionales" En mi humilde opinión, no tendría la costumbre de lanzar excepciones

Answer 5

Es una rotura. Si la API se aplica mediante construcciones de lenguaje o simplemente está documentada es irrelevante.

Si esta rotura causa un problema para el código del cliente es una pregunta diferente. Es posible que esté reparando un defecto y necesite cubrir el caso C2 de esta manera para solucionarlo. Desde ese punto de vista, los desarrolladores de código de cliente pueden estar contentos de que haya realizado este cambio (suponiendo que actualmente no estén solucionando el defecto de tal manera que se rompa de cara al cambio)

Answer 6

Creo que el problema aquí es que usted hizo parte de su interfaz, condiciones específicas de implementación. Si el " C1 " solo eran parte de su implementación, entonces simplemente podría haber creado una nueva implementación que arroje una excepción en '' C1 '' o "C2" sin romper la interfaz.