¿Qué contrato del sistema de tipos obliga a las expresiones switch a proporcionar garantías de exhaustividad en tiempo de compilación al hacer coincidencias de patrones sobre clases selladas?

Respuesta a la pregunta

Historia

El constructo switch evolucionó de una declaración de control de flujo estilo C a una expresión completa capaz de generar valores en Java 14. Con Java 17, se introdujeron clases e interfaces selladas para restringir la herencia, y la coincidencia de patrones para switch surgió como una característica en vista previa, culminando en la estandarización en Java 21. Esta evolución trasladó el switch de una simple tabla de saltos basada en constantes discretas a un sofisticado mecanismo de coincidencia de patrones que debe garantizar la completitud cuando se utiliza como una expresión.

El Problema

Cuando switch opera como una expresión (usando la sintaxis de flecha -> o yield), debe producir un valor para cada posible entrada para satisfacer el sistema de tipos estático de Java. A diferencia de las declaraciones switch tradicionales que pueden omitir silenciosamente casos no manejados o caer a través de ellos, una expresión requiere una certeza absoluta de que todos los caminos de ejecución devuelven un valor. Las jerarquías selladas enumeran explícitamente todos los subtipos permitidos, creando un universo cerrado que hace que la cobertura total sea teóricamente verificable en tiempo de compilación. El compilador debe conciliar este mundo cerrado con patrones abiertos (como patrones de tipo o casos null) para asegurar que no ocurra una MatchException en tiempo de ejecución debido a tipos no cubiertos.

La Solución

El compilador realiza el análisis de dominancia y exhaustividad durante la fase de atribución de la compilación. Trata la cláusula de permisos de una clase sellada como un conjunto finito y cerrado de tipos. Para cada patrón en el switch, resta los tipos coincidentes del universo de tipos permitidos. Si algún subtipo permitido permanece no coincidente después del último patrón, y no existe un default incondicional o un patrón de tipo total, el compilador rechaza el código con un error. Este análisis respeta las reglas de dominancia de patrones (donde los patrones específicos deben preceder a las versiones más generales) y genera maquinaria sintética para manejar entradas null por separado de los patrones de tipo.

sealed interface Payment permits Credit, Debit, Crypto {}
record Credit() implements Payment {}
record Debit() implements Payment {}
record Crypto() implements Payment {}

// Error de tiempo de compilación si falta el caso Crypto
double fee = switch (payment) {
    case Credit c -> 0.02;
    case Debit d -> 0.01;
    // Faltante el caso Crypto causa: "la expresión switch no cubre todos los valores posibles"
};

Situación de la vida real

Descripción del Problema

En un microservicio de procesamiento de pagos, necesitábamos calcular tarifas basadas en tipos de instrumentos: Credit, Debit, BankTransfer y Crypto. El modelo de dominio utilizó una interfaz sellada PaymentInstrument que permite exactamente estas cuatro implementaciones. Un desarrollador junior implementó el cálculo de tarifas usando una expresión switch, pero omitió inadvertidamente el caso Crypto, asumiendo que implícitamente daría cero. Cuando se habilitaron los pagos en criptomonedas en producción, esta omisión provocó una MatchException en tiempo de ejecución, colapsando el pipeline de transacciones y requiriendo una reversión de emergencia.

Diferentes Soluciones Consideradas

Solución A: Caso predeterminado Podríamos agregar una cláusula default -> 0.0 para manejar cualquier instrumento no coincidente. Este enfoque ofrece seguridad inmediata al prevenir el colapso. Sin embargo, oscurece la intención comercial al absorber silenciosamente tipos no manejados. Si más adelante se añadiera un nuevo tipo de instrumento a la jerarquía sellada, la cláusula predeterminada lo ocultaría de los cálculos de tarifas, lo que podría causar pérdidas de ingresos o violaciones de cumplimiento.

Solución B: Mapeo de tipos basado en enum Migrar a un enum InstrumentType permitiría la verificación de exhaustividad en tiempo de compilación mediante enumeración constante. Sin embargo, esto crea una taxonomía paralela que requiere que cada instrumento de pago exponga metadatos de tipo redundantes. Sacrifica la riqueza polimórfica de las clases selladas, donde cada subtipo lleva campos de datos únicos como números de tarjeta o direcciones blockchain, forzando una desnormalización de datos antinatural.

Solución C: Patrones exhaustivos impuestos por el compilador Implementamos la expresión switch con casos explícitos para los cuatro tipos permitidos, aprovechando el análisis de jerarquía sellada del compilador. Este enfoque trata los casos faltantes como errores de compilación, obligando a actualizaciones en la base de código cada vez que cambian los permisos sellados. Elimina sorpresas en tiempo de ejecución al trasladar la verificación hacia la fase de construcción.

Solución Elegida y Resultado

Seleccionamos la Solución C y configuramos el pipeline de construcción para tratar las advertencias del compilador sobre expresiones switch no exhaustivas como errores fatales. Cuando el equipo de producto más tarde añadió BuyNowPayLater como un quinto subtipo permitido, el pipeline de CI/CD marcó inmediatamente diecisiete ubicaciones donde los cálculos de tarifas estaban incompletos. Esto obligó a una actualización coordinada en los módulos de impuestos, cumplimiento y contabilidad antes de la implementación, asegurando que el nuevo instrumento recibiera la lógica financiera adecuada. Las garantías en tiempo de compilación evitaron valores predeterminados silenciosos y mantuvieron la seguridad de tipos a través de equipos distribuidos.

Lo que a menudo los candidatos pasan por alto

¿Cómo interactúa el manejo de null con la verificación de exhaustividad en los switches de patrones?

Muchos candidatos suponen incorrectamente que cubrir todos los subtipos de una clase sellada satisface los requisitos de exhaustividad. Sin embargo, las expresiones switch tratan los selectores null como distintos de los patrones de tipo; se requiere una cláusula case null separada o un patrón total. Sin un manejo explícito de null, el compilador genera un chequeo sintético de null que lanza NullPointerException, lo que significa que la expresión es técnicamente exhaustiva para los tipos, pero no para el valor null en sí.

¿Por qué agregar una cláusula predeterminada a un switch sobre una jerarquía sellada puede violar potencialmente el principio de tipos sellados?

Los candidatos a menudo agregan default como un hábito de codificación defensiva sin reconocer que socava la suposición de mundo cerrado de las clases selladas. Una cláusula predeterminada coincide con cualquier tipo, incluidos aquellos añadidos a la lista de permisos en futuras versiones, efectivamente convirtiendo la verificación de exhaustividad en tiempo de compilación en un catch-all en tiempo de ejecución. Esto reintroduce la fragilidad exacta que las clases selladas estaban diseñadas para eliminar al permitir que tipos nuevos no manejados ejecuten lógica no intencionada silenciosamente.

¿Qué sucede cuando una expresión switch sobre un tipo sellado encuentra un tipo que está permitido pero no es visible para el módulo actual?

Este escenario implica límites de visibilidad donde una clase sellada permite un subtipo de paquete privado en otro paquete o módulo que no está exportado a la unidad de compilación actual. El compilador no puede verificar la exhaustividad porque el conjunto completo de tipos permitidos es desconocido en el sitio de uso, resultando en un error de compilación a pesar de que todos los tipos visibles localmente están manejados. Resolver esto requiere agregar una cláusula predeterminada (lo que derrota la exhaustividad) o ajustar las exportaciones de módulos JPMS para hacer visibles los permisos, destacando la interacción entre la accesibilidad de módulos y la coincidencia de patrones.