Errores en las fronteras: traducir sin filtrar

Todo lo anterior de este nivel es inútil si la traducción entre los dos mundos ocurre en el sitio equivocado, y en la mayoría de los sistemas ocurre en el sitio equivocado por la misma razón: nadie decidió dónde debía ocurrir, así que ocurrió donde alguien tuvo prisa. El síntoma es reconocible y probablemente lo has visto esta semana. Excepciones de la biblioteca de acceso a datos que aparecen tres capas más arriba, en un sitio que no puede saber qué significan. Mensajes de error que llegan al cliente con el nombre de una tabla dentro. La misma incidencia registrada cinco veces con cinco trazas distintas del mismo suceso. Y tareas que siguen corriendo alegremente después de que su ámbito se haya cancelado, porque alguien capturó todo lo capturable y siguió adelante. Ninguno de esos cuatro problemas se arregla eligiendo mejor entre excepciones y valores: se arreglan decidiendo dónde está la frontera y qué se le permite cruzar.

Dónde vive la traducción

Una frontera es cualquier punto donde el código deja de ser tuyo: la llamada al controlador de base de datos, al cliente de red, al analizador sintáctico, al sistema de ficheros. La regla es que la conversión de lanzamiento a valor ocurra en la función que envuelve esa llamada, y no una capa más arriba. El motivo es informativo: solo ahí se sabe todavía qué significa el fallo concreto, porque solo ahí se conoce a la vez la tecnología que lo produjo y la operación de negocio que se estaba intentando.

// Adaptador: unico sitio que conoce la tecnologia
class RepositorioSql(private val ds: DataSource) : RepositorioPedidos {

    override fun buscar(id: PedidoId): Salida<Pedido, ErrorRepositorio> =
        try {
            Salida.Exito(consultar(id))
        } catch (e: SQLTimeoutException) {
            Salida.Fallo(ErrorRepositorio.NoDisponible)
        } catch (e: SQLException) {
            Salida.Fallo(ErrorRepositorio.Averia(e))   // la causa viaja, no el tipo
        }
}

La dirección contraria tiene su propia regla y su propio sitio. Los valores de error del dominio se convierten en algo comprensible para el mundo exterior en el borde del proceso, es decir, en el controlador que responde una petición, en el consumidor de la cola o en el punto de entrada de la aplicación. Ahí, y solo ahí, un caso del dominio se convierte en un código de estado, un mensaje para el usuario o un reintento.

flowchart LR
A[Biblioteca ajena que lanza] --> B[Adaptador: traduce a valor del dominio]
B --> C[Servicio: solo valores, sin capturas]
C --> D[Borde del proceso: traduce a respuesta o a excepcion]
D --> E[Cliente: mensaje estable sin detalles internos]
B -. registro con causa completa .-> F[Diagnostico]
D -. registro unico del desenlace .-> F

Hay una asimetría entre las dos direcciones que conviene explicitar. Hacia dentro, la traducción reduce: muchos tipos de lanzamiento de la biblioteca se colapsan en unos pocos casos que el dominio sabe distinguir, y esa reducción es una decisión de diseño sobre qué diferencias importan de verdad. Hacia fuera, la traducción vuelve a reducir, esta vez desde los casos del dominio hasta el vocabulario del protocolo. Un sistema sano pierde información en los dos bordes y no pierde ninguna en medio.

Entre esos dos extremos, el núcleo no debería contener ninguna captura. Si aparece una, casi siempre indica que la traducción de entrada se hizo demasiado tarde y que el detalle tecnológico se ha filtrado hacia dentro. Esa comprobación es un buen criterio de revisión, porque es fácil de aplicar sin conocer el dominio.

Lo que no debe cruzar hacia fuera

Un tipo de excepción de una biblioteca es un detalle de implementación tan real como el nombre de una clase interna, y dejarlo salir por la firma o por la propagación acopla a todos los consumidores a esa decisión. Cambiar de controlador de base de datos deja de ser un cambio local en cuanto alguien, en cualquier capa, captura el tipo específico que lanzaba el anterior.

El segundo motivo es de seguridad y suele pesar más. Los mensajes de error filtran con enorme facilidad estructura interna: nombres de tablas y columnas, rutas del sistema de ficheros, nombres de máquinas y puertos, fragmentos de consulta, versiones de dependencias. Y filtran también existencia: un mensaje que distingue entre usuario inexistente y contraseña incorrecta permite enumerar cuentas, de modo que la respuesta hacia fuera debe ser la misma aunque el registro interno distinga perfectamente.

// Fuera: estable, generico, con un identificador para correlacionar
data class RespuestaError(val codigo: String, val mensaje: String, val trazaId: String)

// Dentro: todo el detalle, una sola vez, con la causa completa
log.error("fallo al procesar pedido {} en {}", pedidoId, trazaId, e)

La pareja del ejemplo resume la disciplina entera. Hacia fuera viaja un código estable que el cliente puede tratar programáticamente, un mensaje que no revela nada y un identificador de correlación. Hacia dentro queda todo lo demás, asociado a ese mismo identificador, de modo que quien atiende la incidencia puede reconstruir el caso completo a partir de un dato que el usuario sí puede leerle por teléfono sin que eso suponga ninguna filtración.

La cancelación jamás se traga

En corrutinas, la cancelación se implementa lanzando una excepción específica dentro de la corrutina cancelada. Esa excepción no indica ningún error: es la forma que tiene el planificador de pedir a la tarea que termine de forma ordenada. La consecuencia práctica es contundente: cualquier captura ancha dentro de una función suspendida la atrapa, y al atraparla convierte una cancelación cooperativa en una tarea que sigue viva dentro de un ámbito que ya se dio por muerto.

// Roto: la cancelacion queda atrapada y la tarea continua
suspend fun cargar(): Datos? =
    try { pedir() } catch (e: Exception) { null }

// Correcto: la cancelacion vuelve a su camino antes de tratar nada
suspend fun cargarSeguro(): Datos? =
    try {
        pedir()
    } catch (e: CancellationException) {
        throw e
    } catch (e: IOException) {
        null
    }

La diferencia entre los dos fragmentos es de una sola rama y su efecto es enorme. En el primero, cancelar el ámbito no cancela nada: la tarea absorbe la petición, devuelve un valor de respaldo perfectamente plausible y sigue consumiendo recursos dentro de un ámbito que su padre ya considera terminado. En el segundo, la señal continúa su camino y la jerarquía de corrutinas termina como estaba previsto.

Hay tres detalles que conviene tener presentes. El primero es que la excepción de agotamiento de tiempo es un subtipo de la de cancelación, de modo que capturar la segunda de forma amplia también silencia los vencimientos; para tratarlos existe la variante de la operación de tiempo límite que devuelve nulo. El segundo es que la limpieza que debe ejecutarse durante una cancelación necesita un contexto no cancelable, porque en una corrutina ya cancelada cualquier suspensión vuelve a fallar de inmediato. El tercero es que, si no quieres escribir la rama de relanzado, existe la comprobación explícita de actividad del contexto, que vuelve a lanzar si el ámbito está cancelado.

try {
    pedir()
} catch (e: Exception) {
    currentCoroutineContext().ensureActive()   // relanza si hubo cancelacion
    registrar(e)
    null
}

withContext(NonCancellable) {
    cerrarConexion()   // limpieza garantizada aunque el ambito este cancelado
}

Existe además un caso que rompe la intuición de quien ya conoce la regla: dentro de un ámbito concurrente, el fallo de una tarea hija cancela a sus hermanas, de modo que una hermana perfectamente sana recibirá la excepción de cancelación aunque su propio trabajo no tuviera ningún problema. Si esa hermana captura de forma ancha y devuelve un valor de respaldo, el ámbito queda en un estado incoherente donde unas tareas se dieron por canceladas y otras se dieron por terminadas con éxito.

coroutineScope {
    val a = async { primera() }
    val b = async { segunda() }   // si primera falla, esta recibe la cancelacion
    a.await() + b.await()
}

La misma advertencia se aplica a la función de captura universal de la biblioteca estándar y a cualquier bloque que capture el supertipo de lo lanzable. En código con corrutinas, capturar de forma más ancha que un tipo concreto es una decisión que hay que justificar cada vez.