Cuando algo sale mal

¿Qué pasa si el usuario no escribe un número?

En ProductoController tenemos conversiones como esta:

double precio = Double.parseDouble(vista.getTxtPrecio());

Funciona si el usuario escribe 450 o 450.50. Pero imaginemos que escribe:

Java no puede inventar un número que no está ahí. La operación no puede continuar normalmente.

Una excepción interrumpe el flujo normal de una operación

Probemos un ejemplo mínimo, sin Swing:

public class Prueba {
    public static void main(String[] args) {
        String texto = "hola";
        int numero = Integer.parseInt(texto);
        System.out.println(numero);
    }
}

El programa intenta convertir "hola" a int. Como no puede hacerlo, Java genera una excepción.

El texto rojo también nos da información

Un mensaje típico podría comenzar así:

try: intentá ejecutar este bloque

Si sabemos que una operación puede generar una excepción que queremos manejar, podemos colocarla dentro de un bloque try:

try {
    int numero = Integer.parseInt(texto);
}

try no evita el problema ni hace desaparecer la excepción. Solo delimita un bloque cuyo resultado vamos a controlar.

catch: si ocurre esta excepción, ejecutá este bloque

try {
    int numero = Integer.parseInt(texto);
    System.out.println(numero);

} catch (NumberFormatException e) {
    System.out.println("El dato ingresado no es un número válido.");
}

¿Qué código deja de ejecutarse?

try {
    int numero = Integer.parseInt(texto); // aquí ocurre la excepción
    System.out.println("Conversión correcta"); // esta línea se salta
}
catch (NumberFormatException e) {
    System.out.println("Dato inválido");
}

System.out.println("El programa continúa");

Cuando se produce la excepción, Java abandona el resto del bloque try, busca un catch compatible y continúa desde allí.

¿Qué significa catch (NumberFormatException e)?

Ese objeto contiene información. Por ejemplo:

catch (NumberFormatException e) {
    System.out.println(e.getMessage());
}

getMessage() devuelve el mensaje asociado a la excepción.

El Controller puede manejar errores de formato

Ahora el código que antes podía romper la acción queda protegido:

private void agregarProducto() {
    try {
        long codigo = Long.parseLong(vista.getTxtCodigo());
        String nombre = vista.getTxtNombre();
        double precio = Double.parseDouble(vista.getTxtPrecio());
        int stock = Integer.parseInt(vista.getTxtStock());

        // después continuaremos con la operación...

    } catch (NumberFormatException e) {
        JOptionPane.showMessageDialog(
            vista,
            "Código, precio y stock deben ser números válidos"
        );
    }
}

Acá la ubicación tiene sentido: el Controller está interpretando datos que llegan desde la interfaz.

throw: nosotros decidimos que la operación no puede continuar

Supongamos que nuestra regla es: el precio debe ser mayor que cero.

double precio = -450;

Para Java ese valor es un double perfectamente válido. Pero para nuestra aplicación no debería aceptarse.

if (precio <= 0) {
    throw new IllegalArgumentException(
        "El precio debe ser mayor que cero"
    );
}

Leamos la línea por partes:

El Service puede lanzar; el Controller puede capturar

En ProductoService:

if (precio <= 0) {
    throw new IllegalArgumentException(
        "El precio debe ser mayor que cero"
    );
}

El Service comunica: “no puedo realizar esta operación”.

En ProductoController:

try {
    service.agregarProducto(codigo, nombre, precio, stock);

} catch (IllegalArgumentException e) {
    JOptionPane.showMessageDialog(vista, e.getMessage());
}

El Controller decide: “¿cómo se lo explico al usuario?”.

¿Por qué no usar simplemente un if y return?

if (precio <= 0) {
    return;
}

if (precio <= 0) {
    throw new IllegalArgumentException(
        "Precio inválido"
    );
}

Esto no significa que todo if deba convertirse en excepción. Los if sirven para tomar decisiones normales del programa. Una excepción tiene sentido cuando estamos diciendo: esta operación no puede continuar como fue solicitada.

Java tiene muchas excepciones; hoy necesitamos unas pocas ideas firmes

Las excepciones con las que estamos trabajando pertenecen a la familia de excepciones de ejecución. Más adelante veremos otras situaciones en las que Java obliga a declarar o manejar determinadas excepciones.

Probamos, provocamos y manejamos

Casos para probar

No alcanza con reconocer la sintaxis

Una aplicación robusta no supone que todo saldrá bien

Micro-entrega de documentación

Completá para Tienda de Cómics una tabla como esta:

Puente: ahora ya podemos volver a ProductoService sin que throw e IllegalArgumentException aparezcan de la nada. Sabemos qué significan y cómo viaja el problema hasta quien debe manejarlo.