En Rust, panic! es un fallo deliberado. El programa imprime un rastreo de pila y termina. En código de prueba, los panics son el mecanismo estándar para aserciones -- cada assert!, assert_eq!, y unwrap() es un panic potencial, y así está diseñado. En código de producción, los panics son casi siempre errores. Convierten lo que debería ser un error manejado en un fallo del proceso, y en un runtime de lenguaje como FLIN, un fallo significa que cada aplicación ejecutándose en ese runtime se cae.
La auditoría de FLIN catalogó cada llamada panic en 186.252 líneas de código Rust. El número bruto era alarmante: más de 800 sitios de panic en todo el código base. El número refinado era tranquilizador: solo 5 estaban en rutas de código de producción. El resto eran aserciones de prueba, que es exactamente donde los panics pertenecen.
Este artículo rastrea esos cinco panics de producción -- dónde viven, por qué existen, si deberían ser eliminados, y cómo luce la estrategia de eliminación.
El censo de panics
La auditoría contó las llamadas panic en tres niveles: invocaciones explícitas de la macro panic!(), llamadas .unwrap() en tipos Result y Option, y llamadas .expect() que proporcionan un mensaje antes de provocar el panic. Juntos, estos forman el conjunto completo de sitios de panic en el código base.
Module Explicit panic! .unwrap() .expect() Total
codegen/bytecode.rs 2 0 0 2
vm/vm.rs 48 0 0 48
vm/renderer.rs 9 0 0 9
parser/parser.rs ~600 0 0 ~600
tests/** 0 ~120 ~20 ~140
-----
TOTAL ~659 ~120 ~20 ~799Los cinco panics de producción
Después de filtrar los panics que solo eran alcanzables a través de rutas de código internas, la auditoría identificó cinco panics que un desarrollador FLIN podría teóricamente provocar:
PANIC-001: Desbordamiento del pool de constantes
rust// codegen/bytecode.rs line 1711
pub fn add_constant(&mut self, value: Value) -> u16 {
if self.constants.len() >= u16::MAX as usize {
panic!("Constant pool overflow: too many constants (max {})", u16::MAX);
}
self.constants.push(value);
(self.constants.len() - 1) as u16
}Veredicto: Convertir de panic! a un CompileError::ConstantPoolOverflow que produzca un mensaje de error amigable indicando al desarrollador que divida su programa en módulos.
PANIC-002: Aserción de tipo Float
Veredicto: Convertir a Result para un reporte de errores más limpio, pero marcar como baja prioridad ya que la condición debería ser inalcanzable.
PANIC-003 a PANIC-050: Aserciones de tipo de la VM
La VM contiene 48 llamadas panic, casi todas siguiendo el mismo patrón de aserción de tipo. Estos son los panics más importantes a eliminar. Un desarrollador FLIN que pase el tipo incorrecto a una función integrada debería recibir un error de runtime claro, no un fallo del proceso.
Veredicto: Convertir los 48 a retornos VmError::TypeError. Esta es la tarea de eliminación de panics de mayor prioridad.
PANIC-051 a PANIC-059: Aserciones del renderizador
El renderizador contiene 9 llamadas panic, principalmente en evaluación de expresiones y generación de HTML.
Veredicto: Convertir a degradación elegante -- renderizar un marcador de error visible en la salida HTML y registrar una advertencia, pero nunca hacer fallar el proceso del servidor.
La estrategia de eliminación
La auditoría propuso una estrategia de tres niveles:
Nivel 1: Convertir a VmError (48 panics de VM). Trabajo mecánico pero toca 48 sitios de llamada.
Nivel 2: Convertir a degradación elegante (9 panics del renderizador). Las expresiones de plantilla que fallen al evaluarse deberían renderizar [Error: expected text, got map] en modo desarrollo y como cadena vacía en producción.
Nivel 3: Convertir a CompileError (2 panics de codegen). La prioridad más baja porque son los más difíciles de provocar.
Por qué importan cero panics
Un runtime de lenguaje es infraestructura. Cuando un desarrollador FLIN escribe una aplicación web y la despliega en producción, confía en que el runtime no fallará ante ninguna entrada que sus usuarios proporcionen. Un panic en el runtime no es solo un error en FLIN -- es tiempo de inactividad para cada aplicación construida sobre FLIN.
Cero panics de producción no es un objetivo teórico. Es una propiedad concreta y medible del binario. O las llamadas panic! existen en rutas de código de producción, o no existen. La auditoría nos dio la lista exacta. Las sesiones de corrección las eliminarían. Y el pipeline de CI aseguraría que nunca regresen.
Esta es la Parte 154 de la serie "Cómo construimos FLIN", que documenta cómo un CEO en Abidjan y un CTO de IA diseñaron y construyeron un lenguaje de programación desde cero.
Navegación de la serie: - [153] Lo que la auditoría nos enseñó sobre construir un lenguaje - [154] Llamadas panic en producción: rastreo y eliminación (estás aquí) - [155] 93 sesiones auditadas en un solo pase