Sin excepciones comprobadas: la decisión de diseño

Kotlin no eliminó las excepciones comprobadas por pereza ni por seguir una moda: las eliminó después de que el único lenguaje de masas que llegó a implementarlas tuviera dos décadas para demostrar que funcionaban, y el veredicto de esas dos décadas fue que el mecanismo producía más ruido que seguridad. Conviene enunciarlo con precisión, porque la frase de manual suena a simplificación y esconde una tesis bastante más interesante sobre dónde debe vivir la información de que algo puede fallar. La tesis es esta: el compilador puede verificar que una función declara un fallo, pero no puede verificar que quien la llama esté en condiciones de hacer algo útil con él, y una comprobación que solo alcanza la mitad del problema acaba satisfecha con gestos vacíos que además silencian el fallo de verdad. Esta lección examina la evidencia, mide sin adornos lo que se pierde al retirar el aviso del compilador, y explica qué sigue haciendo @Throws en un lenguaje que decidió no comprobar nada.

La garantía que Java quiso dar y por qué se rompió

La idea original era razonable y sigue siéndolo: si una operación puede fallar de forma previsible, ese fallo debería formar parte de su firma igual que forma parte el tipo de retorno, y el compilador debería negarse a compilar a quien lo ignore. Java implementó esa idea partiendo el árbol de excepciones en dos ramas, obligando a declarar o capturar las de una rama y dejando libre la otra. Ningún otro lenguaje de adopción masiva repitió el experimento, y esa unanimidad posterior no es casual.

Conviene recordar la mecánica exacta antes de criticarla, porque la crítica solo es justa si se dirige al mecanismo real. La rama libre está formada por los fallos que descienden del tipo de excepción en tiempo de ejecución y por los errores irrecuperables de la máquina; todo lo demás pertenece a la rama comprobada y obliga. La frontera, por tanto, no la traza ninguna propiedad del fallo: la traza la posición de la clase en una jerarquía de herencia decidida de antemano.

El primer problema es de categoría. Que un fallo sea recuperable no es una propiedad de la función que lo produce, sino de la que la llama. Una función de lectura de fichero no puede saber si su invocador tiene un plan alternativo, si está en un reintento, si está dentro de una tarea de fondo que puede abortarse o si está en un arranque donde cualquier fallo debe tumbar el proceso. Java pidió a quien escribe la función una decisión que solo puede tomar quien la usa, y el resultado previsible fue que la obligación cayera sobre gente sin contexto para cumplirla.

// La reacción más frecuente del programador obligado no es manejar el fallo:
try {
    return leerFichero(ruta);
} catch (IOException e) {
    throw new RuntimeException(e);   // el aviso se convierte en ceremonia
}

El segundo problema es de composición. La cláusula de declaración forma parte del tipo del método, así que se propaga hacia arriba de forma viral y obliga a modificar firmas de capas que nada tienen que ver con el fallo. Peor aún, las interfaces funcionales de la biblioteca no declaran nada, de modo que en cuanto la lambda que se pasa a una operación de flujo necesita hacer entrada y salida, el sistema entero deja de encajar y hay que envolver, adaptar o rendirse.

// La interfaz funcional no declara nada, asi que esto no compila
Stream<String> textos = rutas.stream().map(ruta -> Files.readString(ruta));

El tercer problema es de evolución. Como la cláusula pertenece a la firma, añadir un fallo declarado nuevo a una función publicada rompe la compilación de todos sus consumidores, lo que convierte cualquier cambio interno en un cambio incompatible. El resultado perverso es que quien mantiene una biblioteca aprende a no declarar fallos nuevos jamás, y prefiere envolverlos en algo no comprobado precisamente para no molestar. El mecanismo termina desincentivando la sinceridad que pretendía imponer.

Lo que se gana y lo que se pierde

En Kotlin toda excepción es no comprobada. El compilador no obliga a capturar nada, y además ignora deliberadamente las cláusulas de declaración de los métodos Java que llama: puedes invocar un método que declara un fallo de entrada y salida sin escribir un solo try. El fallo sigue existiendo y sigue viajando por la pila exactamente igual; lo único que ha desaparecido es la verificación estática.

import java.io.File

// El método Java subyacente declara IOException. Aquí no hace falta nada.
fun cargar(ruta: String): String = File(ruta).readText()

flowchart TD
A[Metodo Java que declara IOException] --> B{Quien lo invoca}
B -- Codigo Java --> C[Obligado a capturar o a declarar]
B -- Codigo Kotlin --> D[Sin obligacion: la clausula se ignora]
C --> E[El fallo ocurre igual en tiempo de ejecucion]
D --> E

La ganancia es real y va mucho más allá de escribir menos. Las lambdas vuelven a componer sin fricción, porque ningún tipo función necesita declarar fallos; las abstracciones genéricas dejan de partirse en dos variantes; las corrutinas pueden propagar errores a través de fronteras de suspensión sin inventar firmas paralelas; y desaparece por completo el bloque escrito solo para callar al compilador, que era el sitio donde más errores se perdían de verdad.

La pérdida también es real y merece nombrarse sin defensa. Al leer una llamada ya no hay ninguna marca sintáctica que avise de que puede fallar, y la única fuente de verdad es la documentación, el código fuente o la experiencia. Cuando una refactorización introduce un fallo nuevo en una función profunda, nada avisa a los treinta sitios que la llaman; el aviso, si llega, llega en producción.

Conviene observar cómo responde a esa pérdida la propia biblioteca estándar, porque su respuesta anticipa todo el nivel. Para las operaciones que fallan de forma previsible ofrece pares de funciones: una que lanza y otra que devuelve nulo. La segunda no necesita ninguna comprobación especial del compilador, porque la posibilidad de fallo ya está en el tipo de retorno y el sistema de nulabilidad la verifica con las reglas ordinarias.

val a: Int = texto.toInt()          // lanza si el formato es invalido
val b: Int? = texto.toIntOrNull()   // el fallo esta en el tipo, comprobado

// El compilador obliga a tratar el caso, sin reglas especiales
val puerto = texto.toIntOrNull() ?: 8080

Ese par de funciones enseña dónde se ha mudado la comprobación. La versión que lanza sigue existiendo para el caso en que un formato inválido signifique de verdad que el programa está roto; la que devuelve un tipo nulable existe para el caso, mucho más frecuente, en que el texto venga de un usuario y un formato inválido sea el funcionamiento normal. Kotlin no eligió por ti: te dio las dos y trasladó la decisión al sitio donde se puede tomar con información, que es el punto de llamada.

El corolario práctico es incómodo pero clarificador: si retiras el aviso del compilador y no pones nada en su lugar, has empeorado la situación. Las tres lecciones siguientes tratan precisamente de con qué se sustituye, y la respuesta corta es que los fallos que de verdad importan al dominio no deberían viajar como excepciones sino como valores del tipo de retorno, donde el compilador vuelve a poder verificarlos sin ninguna regla especial.

@Throws y la frontera hacia otros lenguajes

Kotlin genera bytecode sin cláusula de propagación, y eso tiene una consecuencia visible para quien consume la biblioteca desde Java. Si un método Kotlin lanza un fallo de entrada y salida pero no lo declara, el compilador de Java rechazará un bloque que intente capturarlo, con el argumento de que esa excepción nunca se lanza en el bloque correspondiente. El consumidor queda atrapado entre un fallo que ocurre y un lenguaje que le niega el permiso para tratarlo.

La situación es más incómoda de lo que parece porque el fallo sí ocurre: simplemente el compilador de Java, que solo mira la firma declarada, ha decidido que no puede ocurrir. El consumidor acaba capturando el supertipo de todas las excepciones para poder tratar algo, con lo que la ausencia de una anotación en tu biblioteca ha provocado exactamente la captura demasiado ancha que el resto de este nivel intenta evitar.

Para eso existe @Throws. No cambia absolutamente nada del lado Kotlin: no obliga a nadie, no genera comprobaciones y no altera el flujo. Lo único que hace es emitir la cláusula en el bytecode para que el otro lado del puente la vea.

import java.io.File
import java.io.IOException

@Throws(IOException::class)
fun leerConfiguracion(ruta: String): String = File(ruta).readText()

Hay tres situaciones en las que la anotación deja de ser cortesía y pasa a ser obligatoria. La primera es implementar una interfaz Java cuyo método declara un fallo, porque la firma sobrescrita debe encajar. La segunda es cualquier biblioteca pensada para consumo desde Java, donde omitirla convierte el manejo correcto en un rodeo. La tercera es Kotlin nativo con destino a Swift y Objective-C, donde la anotación es lo que traduce el lanzamiento a la convención de error del anfitrión; sin ella, el fallo cruza la frontera como una terminación abrupta del proceso.

class Recurso : AutoCloseable {
    // Sin la anotacion, la firma generada no declara nada y Java se queja
    @Throws(Exception::class)
    override fun close() { liberar() }
}

Hay una consecuencia menos evidente y que afecta a las bibliotecas multiplataforma. Como la anotación describe tipos de la plataforma anfitriona, solo puede escribirse donde esos tipos existen, de modo que una declaración común no puede llevarla y hay que colocarla en la implementación específica de cada objetivo. Esa restricción empuja de forma natural hacia el diseño que este nivel defiende: el código común expresa sus fallos como valores, y las excepciones quedan confinadas en las implementaciones que tocan cada plataforma.

Para el consumo desde Kotlin, el sustituto de la anotación no es sintáctico sino documental. La etiqueta de documentación que describe los lanzamientos posibles no genera ninguna comprobación, pero sí aparece en la ayuda del editor y en la documentación publicada, que es el único canal que le queda a quien lee la firma. Escribirla en las funciones públicas que lanzan de forma deliberada no es una formalidad: es lo que queda del contrato después de retirar la verificación.