Developing Frogtek

El blog del Departamento de Tecnología

Excepciones para controlar tu lógica

Hace unos días apareció en nuestro board una User Story que tenía como título:

“Pop-up warning when Cost is higher than Price”

En sus AT’s aparecían las pantallas donde debería hacerse esta comprobación. Así que nos pusimos manos a la obra y estudiamos cuál sería el impacto de este cambio. Vimos que tendríamos que añadir una condición en todas las pantallas y en todos los sitios donde son susceptibles de cambio las dos variables que nos atañen.

Si optábamos por ese camino, esto iba a oler a bug, en el que te reportan que no se muestra el pop-up en un lugar que no tuviste en cuenta a la hora de añadir la condición. Con lo que decidimos no optar por la solución a priori mecánica y sencilla. De repente, la palabra “Excepciones” vino a nuestras mentes, Rubén de Biko2 estuvo durante tres días inculcando su sabiduria en el equipo de Frogtek y algo de lo que nos contó salía a la luz.

Así que decidimos implementarnos una excepción que se lanzase desde la lógica hacia la UI si esta condición se daba. De este modo el impacto sería mucho menor y desde la UI solo tendríamos que controlar dicha excepción y mostrar el pop-up, y además sería imposible saltarnos ningún sitio, puesto que tendríamos error de compilación. Así quedo nuestra clase:

package org.frogtek.tiendatekcore.exceptions;
  public class CostHigherThanPriceException extends Exception {
        public CostHigherThanPriceException() {
            super("Cost is higher than price");
        }
    }

En este caso el mensaje no es importante para nosotros: solo queremos capturar el momento en el que sucede esta condición.

El método del bean que lanzaba la excepción quedaría así:

    public void setPurchaseCost(long purchaseCost) throws CostHigherThanPriceException {
        if (purchaseCost != this.mPurchaseCost) {
            if (this.mPurchasePrice < purchaseCost) {
                throw new CostHigherThanPriceException();
            } else {
                this.mPurchaseCost = purchaseCost;
            }
        }
    }

Después de esto surgieron por la oficina las dudas filosóficas de si estabamos tomando el camino correcto al usar excepciones para esto, o de si un excepción no debería controlar solo errores que no se pueden manejar. Esta es la definición oficial de java:

An exception is an event that occurs during the execution of a program that disrupts the normal flow of instructions.

Muy abierta y si os dais cuenta no habla en ningún momento de errores. Habla de eventos.

Conclusiones que en Frogtek hemos obtenido:

  • Que tener a una persona de fuera de la oficina con el espíritu y con las ganas de hacer bien las cosas es increíble.
  • Que usar excepciones es una muy buena estrategia para definir tu lógica. Nosotros somos un equipo de 7 personas tocando y retocando el mismo código a diario. Ayuda mucho que tú tengas que llamar a un método que lance una excepción: desde el primer momento estás advertido de que ese método puede lanzar algo y estás en la obligación de controlarlo.

5 Comentarios

  1. Y no olvides que gracias a las excepciones, encontramos un fallo en el flujo de la aplicación 😉

    • Correcto. Es otra ventaja que todo lo tienes a prueba de bombas. Si tienes tu core controlado con este sistema o uno parecido no tendrás valores que no cumplan tu lógica de negocio en tu aplicación.

  2. Hola chicos, interesantísimo artículo sobre Exceptions, ¡¡me ha encantado leer este caso práctico de uso!!

    Quisiera añadir algo a vuestra duda sobre si los padres de java consideran a “Exception” un error.

    Aunque supongo que ya lo sabéis de sobra, os comento:
    En Java existen dos grupos diferenciados de Exceptions: JVM Thrown exception y Programatically Thrown Exceptions. (según aprendí con SCJP6)

    Las primeras serían las propias de la maquina virtual, incluye tanto a errores como excepciones propias de java (NullPointer… StackOverflow… etc etc)

    La segundas serían aquellas que son creadas por la aplicación y/o el desarrollador de la API.

    En mi opinión personal, creo que habéis escogido muy correctamente la forma de lanzar la Exception programada, y que en este caso al ser “propia” vuestra se puede usar para controlar desde vuestra validación en el bean que hay un error provocado por el cálculo de coste/precio.

    Perdón por el tocho… me emocioné jejeje.
    Saludos
    Raúl

    • Hola Raúl:
      De rollo nada, muy interesante tu aportación sobre diferencias entre excepciones. También en su día miramos la posibilidad de las clases Error y RuntimeException. Estás son para lanzarlas en tiempo de ejecución y el compilador no te saltará diciendo que has te implementar el try/catch. Son muy potentes, pero claro… puedes hacer que tu app se rompa sin darte cuenta antes. Así que decimos usar exception para obligarnos a nosotros mismos a cogerla y manejarla.
      Personalmente me parece una técnica increíble.
      En Frogtek nos hemos hecho a ella y la estamos usando a lo largo de toda la aplicación.

      • Claro!, usar exceptions es ideal.

        Esas Exceptions que comentas Error y Runtimexception no deberían ser lanzadas mas que por la JVM ya que te informa de un problema ajeno a tu lógica de programación.
        Por ejemplo las StackOverflowError (has sobrepasado el límite en una recursividad) o la típica de “uy!” me pasé de cuentas en un bucle for y le estoy metiendo un valor a la posicion 200 de una lista de 199…ArrayIndexOutOfBoundsException. Yo creo que se deben tener en cuenta pero no usar para lanzarlas porque no eres tu la maquina virtual.

        Me alegro que te parezca interesante!!.

        Saludos
        Raúl

Deja un comentario

Tu dirección de correo electrónico no será publicada.

*