Jerarquía de excepciones MultagalException

1Comprobadas vs. no comprobadas

Antes de diseñar la jerarquía, ten clara la diferencia: define si MultagalException obligará al llamador a capturarla o no.

• Diseñar MultagalException como raíz no comprobada (extiende RuntimeException)

2Subtipos de dominio

Al menos una excepción para «no encontrado» y otra para fallos de almacenamiento — las que ya necesitan A1.1 y A1.2.

public class MultagalException extends RuntimeException {
    public MultagalException(String mensaje, Throwable causa) {
        super(mensaje, causa);
    }
}

public class ExpedienteNoEncontradoException extends MultagalException {
    public ExpedienteNoEncontradoException(String numero, Throwable causa) {
        super("No existe el expediente: " + numero, causa);
    }
}

public class AlmacenamientoException extends MultagalException {
    public AlmacenamientoException(String mensaje, Throwable causa) {
        super(mensaje, causa);
    }
}

• Crear ExpedienteNoEncontradoException como subtipo de MultagalException
• Crear una excepción de almacenamiento (p. ej. AlmacenamientoException) como subtipo de MultagalException

3Traducir las excepciones de bajo nivel

Revisa el código de A1.1 (AlmacenExpedientes), A1.2 (ServicioPurgaExpedientes) y A1.3 (VigilanteBuzonEntrada): ningún método público debe dejar escapar IOException sin traducir.

public Optional<Path> buscar(String numeroExpediente) {
    try (Stream<Path> stream = Files.walk(raiz)) {
        return stream
                .filter(Files::isRegularFile)
                .filter(p -> coincide(p, numeroExpediente))
                .findFirst();
    } catch (IOException e) {
        throw new AlmacenamientoException(
                "Error de E/S al buscar el expediente " + numeroExpediente, e);
    }
}

• Revisar A1.1, A1.2 y A1.3 y traducir cada IOException capturada a la excepción de dominio correspondiente
• Conservar siempre la excepción original como causa del constructor
• Verificar que ningún método público de las tres actividades deja escapar IOException sin traducir

4try-with-resources en todo recurso AutoCloseable

Aprovecha la revisión para confirmar que todo Stream<Path>, WatchService u otro recurso cerrable de A1.1–A1.3 usa try-with-resources y no un finally manual.

// Varios recursos: se cierran en orden inverso, incluso si hay excepción
try (Stream<Path> stream = Files.walk(raiz);
     WatchService watcher = FileSystems.getDefault().newWatchService()) {
    // ...
}

• Confirmar que todo recurso AutoCloseable de A1.1, A1.2 y A1.3 se cierra con try-with-resources

5Diario técnico

Justifica por escrito por qué la raíz de la jerarquía es no comprobada.

• Documentar en el diario técnico por qué MultagalException es una excepción no comprobada

!Problemas frecuentes

✓Criterios de aceptación

• MultagalException extiende RuntimeException
• Cada excepción de dominio conserva la excepción original como causa
• Ningún método público de A1.1–A1.3 deja escapar IOException sin traducir
• Todo recurso AutoCloseable usa try-with-resources
• El diario técnico justifica por qué la raíz es no comprobada