Modelar el fallo como valor: sealed, Either y comparación

La afirmación de que conviene modelar los fallos como valores se repite tanto que ha perdido casi todo su contenido, y quien la aplica sin entenderla suele acabar con una jerarquía de treinta casos de error que nadie distingue y con capas enteras dedicadas a traducir un tipo de error en otro. La afirmación correcta es más estrecha y más útil: cuando quien escribe una función ya conoce y puede enumerar las formas en que termina mal, esa información existe en el momento de escribir la firma y tirarla es una pérdida gratuita, porque el sistema de tipos de Kotlin puede transportarla intacta hasta el invocador y obligarle a mirarla. Lo que esta lección se propone es mostrar cómo se construye esa jerarquía sin que degenere, presentar honestamente el precio que se paga en encadenamiento y en propagación entre capas, y poner las tres opciones disponibles una al lado de otra sin declarar un ganador universal, porque no lo hay.

El tipo suma como desenlace de la operación

La construcción básica es directa: una interfaz sellada cuyos casos son los desenlaces posibles, consumida en un when que el compilador exige exhaustivo. La ganancia inmediata es que añadir un caso nuevo rompe la compilación en todos los sitios que lo consumen, que es exactamente la comprobación que las excepciones comprobadas prometían y no lograban dar de forma composicional.

sealed interface Retirada {
    data class Ok(val saldoRestante: Dinero) : Retirada
    data class SaldoInsuficiente(val disponible: Dinero) : Retirada
    data object CuentaBloqueada : Retirada
    data class LimiteDiarioSuperado(val limite: Dinero) : Retirada
}

fun retirar(cuenta: Id, importe: Dinero): Retirada = // ...

when (val r = retirar(cuenta, importe)) {
    is Retirada.Ok -> mostrarSaldo(r.saldoRestante)
    is Retirada.SaldoInsuficiente -> ofrecerRecarga(r.disponible)
    Retirada.CuentaBloqueada -> abrirSoporte()
    is Retirada.LimiteDiarioSuperado -> explicarLimite(r.limite)
}

Toda la garantía de ese fragmento descansa en un detalle fácil de destruir: no hay rama comodín. En el momento en que alguien añade una rama final que agrupa el resto de casos, el compilador deja de tener nada que exigir y la jerarquía sellada pasa a costar lo mismo que antes sin dar nada a cambio. La rama comodín es aceptable cuando el consumidor pertenece a otro módulo y quiere sobrevivir a la aparición de casos nuevos; dentro del propio módulo es casi siempre una renuncia disfrazada de prudencia.

Ese diseño tiene un defecto que aparece a la tercera operación: si cada una declara su propio tipo con su caso de éxito dentro, el caso de éxito y los de fallo quedan mezclados en la misma jerarquía y no se pueden reutilizar. La corrección consiste en separar los dos ejes, dejando el éxito como parámetro genérico y sellando únicamente el error.

sealed interface Salida<out T, out E> {
    data class Exito<T>(val valor: T) : Salida<T, Nothing>
    data class Fallo<E>(val error: E) : Salida<Nothing, E>
}

sealed interface ErrorRetirada {
    data class SaldoInsuficiente(val disponible: Dinero) : ErrorRetirada
    data object CuentaBloqueada : ErrorRetirada
}

El contenedor de dos ramas y su letra pequeña

Ese tipo genérico de dos parámetros tiene nombre y tradición: es el contenedor conocido como Either, con una rama izquierda para el fallo y una derecha para el éxito. En Kotlin no está en la biblioteca estándar y llega mediante una biblioteca externa, típicamente Arrow, que además aporta lo que hace que el patrón sea utilizable: las operaciones de encadenamiento.

La diferencia con un tipo sellado propio es menor de lo que parece y consiste sobre todo en herramientas. El tipo del dominio se lee mejor porque sus casos tienen nombres del negocio; el contenedor genérico se compone mejor porque trae un catálogo de operaciones ya escrito y compartido por todo el ecosistema. Ambos son el mismo tipo suma por debajo.

flowchart TD
A[La operacion puede terminar mal] --> B{Puedo enumerar los fallos ahora}
B -- No --> C[Excepcion documentada y traducida en la frontera]
B -- Si --> D{Al invocador le sirve distinguirlos}
D -- No, solo si hubo fallo --> E[Tipo nulable]
D -- Si --> F{Necesito encadenar muchas operaciones}
F -- No --> G[Tipo sellado propio del dominio]
F -- Si --> H[Contenedor de dos ramas con encadenamiento]

Aquí está el precio real y el motivo por el que muchos equipos abandonan el enfoque a mitad de camino. Kotlin no tiene notación para secuenciar operaciones que devuelven un tipo envuelto, de modo que encadenar cinco pasos donde cualquiera puede fallar produce o bien una escalera de anidamiento, o bien una cadena de transformaciones aplanadas que se lee peor que el código original. La respuesta de Arrow es un ámbito con capacidad de interrupción que devuelve la apariencia secuencial, y es una buena respuesta, pero es una dependencia y una forma de escribir que el equipo entero debe conocer.

// Sin ayudas: el anidamiento crece con cada paso
val salida = validar(entrada).flatMap { v ->
    autorizar(v).flatMap { a ->
        ejecutar(a)
    }
}

// Con un ambito de interrupcion: vuelve a leerse como una secuencia
fun procesar(entrada: Entrada): Either<ErrorProceso, Recibo> = either {
    val v = validar(entrada).bind()
    val a = autorizar(v).bind()
    ejecutar(a).bind()
}

El segundo precio es la propagación entre capas. Si el repositorio devuelve su error, el servicio el suyo y el controlador el suyo, hacen falta funciones de traducción en cada salto, y ese trabajo es real. La mitigación habitual es tener pocos tipos de error, definidos por capa y no por operación, y aceptar que la capa más externa colapse todo en una representación de transporte.

Los tres enfoques, comparados sin favoritismo

La comparación se ve mejor sobre la misma operación escrita tres veces, porque revela que lo que cambia no es la implementación sino la cantidad de información que la firma entrega al invocador antes siquiera de ejecutarse.

fun cobrar(t: Tarjeta): Recibo                          // puede lanzar, la firma calla
fun cobrar(t: Tarjeta): Result<Recibo>                  // puede fallar, no dice de que
fun cobrar(t: Tarjeta): Salida<Recibo, ErrorCobro>      // dice exactamente de que

Hay un cuarto candidato que conviene no olvidar porque suele ser la respuesta correcta y casi nunca se considera: el tipo nulable. Cuando la operación solo puede fallar de una manera y quien la llama no necesita saber más que si hubo valor o no, devolver un tipo nulable da exhaustividad, coste nulo y cero infraestructura. Escribir una jerarquía sellada de un solo caso de error es un gasto sin contrapartida.

Tampoco conviene olvidar que los tres enfoques conviven sin contradicción en un mismo sistema, y que un proyecto sano usa los tres a la vez en sitios distintos. Las averías de infraestructura viajan como excepciones hasta el borde del proceso; la frontera con bibliotecas ajenas usa el contenedor genérico durante unas pocas líneas; y las reglas del negocio, que son las que el compilador puede ayudar a no olvidar, viajan como tipos del dominio. Presentar la elección como una guerra entre bandos es el error de partida.

// Los tres, cada uno en su sitio, dentro de la misma funcion
fun procesarPago(p: Peticion): Salida<Recibo, ErrorPago> {
    val tarjeta = validar(p) ?: return Salida.Fallo(ErrorPago.TarjetaInvalida)
    return runCatching { pasarela.cobrar(tarjeta) }        // frontera ajena
        .fold(
            onSuccess = { Salida.Exito(it) },
            onFailure = { Salida.Fallo(ErrorPago.desde(it)) },   // traduccion
        )
}

El criterio de elección que resiste la práctica combina dos preguntas. La primera es si los fallos son enumerables en el momento de escribir la firma; si no lo son, ninguna cantidad de tipos lo arreglará y el canal de excepciones con traducción en la frontera es lo honesto. La segunda es si el invocador inmediato tiene algo distinto que hacer según el caso; si no lo tiene, distinguirlos es ceremonia. Solo cuando ambas respuestas son afirmativas el tipo del dominio paga su precio.