Errores en la práctica: envolver, propagar y no tragarse nada

Las cuatro lecciones anteriores describieron un mecanismo. Esta describe una disciplina, que es otra cosa. En un programa real los errores no llegan del ejemplo de tres funciones anidadas: llegan de una biblioteca de terceros que a veces lanza cadenas y a veces devuelve nulo, de una corrutina que murió hace dos ciclos, de un metamétodo que se ejecutó en un momento que nadie eligió, y de un manejador de errores que falló mientras intentaba explicar el fallo anterior. Lo que sigue es el conjunto de prácticas que separan un sistema en el que un incidente se diagnostica leyendo una línea de registro de otro en el que se diagnostica reproduciendo el estado durante dos días.

La frontera: envolver y propagar

Una dependencia externa es una fuente de fallos con convenciones que no controlas. Puede lanzar cadenas en unos casos y tablas en otros, devolver nulo sin mensaje, o lanzar valores numéricos que en tu registro aparecerán como cifras sin contexto. La respuesta profesional no es adaptarte a ella en cada punto de uso, sino escribir una capa fina que la normalice una sola vez.

local ajena = require("biblioteca_ajena")

local M = {}

local function normalizar(err)
  if type(err) == "table" then return err end
  return { clase = "ajena", mensaje = tostring(err) }
end

function M.consultar(clave)
  local ok, res = pcall(ajena.query, clave)
  if not ok then return nil, normalizar(res) end
  if res == nil then return nil, { clase = "ajena", mensaje = "sin resultado" } end
  return res
end

return M

La capa cumple tres funciones a la vez: convierte cualquier forma de fallo en una sola, impide que un tipo de la dependencia se filtre al resto del programa, y concentra en un fichero el trabajo del día en que esa dependencia cambie de convención. Ninguna de las tres se consigue capturando errores en cada punto de uso.

Conviene además que la frontera sea estrecha en el sentido literal: cuanto menor sea la superficie de la dependencia que atraviesa tu envoltorio, menos código tuyo dependerá de sus detalles. Un envoltorio que expone cuarenta funciones de la biblioteca ajena porque algún día podrían hacer falta no es una frontera, es una redirección. Envuelve solo lo que usas, y añade lo demás el día que lo necesites.

La segunda mitad del trabajo de frontera es la propagación. Un mensaje que dice que el fichero no existe es inútil si no dice qué fichero ni por qué se estaba abriendo. Añadir esa información al subir es la práctica que más reduce el tiempo de diagnóstico, y tiene una regla técnica concreta: al relanzar, usa nivel cero.

local function cargarPerfil(usuario)
  local ok, err = pcall(leerFichero, rutaDe(usuario))
  if not ok then
    error(string.format("al cargar el perfil de %s: %s", usuario, tostring(err)), 0)
  end
end

Sin ese cero, el mensaje resultante llevaría dos posiciones encadenadas: la del error original, que ya venía dentro del texto, y la de la línea donde relanzas, que no aporta nada porque el rastro ya la contiene. Con errores estructurados el equivalente es guardar el error interior en un campo, formando una cadena de causas que el registro final puede recorrer entera.

No tragarse errores

El antipatrón más extendido cabe en una línea, y por eso se cuela en las revisiones de código sin que nadie lo señale.

pcall(guardarEstado)             -- si falla, nadie lo sabra jamas

La llamada protegida cuyo resultado se descarta convierte un fallo ruidoso en un silencio, y el silencio es el modo de fallo más caro que existe. Hay exactamente tres razones legítimas para capturar un error, y ninguna de ellas es evitar que el programa se detenga.

Limpiar sin bloque final

Como el desenrollado no ejecuta código de limpieza, un error que atraviesa un ámbito deja abierto lo que hubiera abierto. Hay dos soluciones, y la moderna es claramente superior.

-- Lua 5.4: la variable de cierre se libera salga como salga el bloque
local function procesar(ruta)
  local f <close> = assert(io.open(ruta, "r"))
  return analizar(f:read("a"))     -- si analizar lanza, f se cierra igual
end

-- Compatible con versiones anteriores: capturar, limpiar, relanzar
local function procesarCompat(ruta)
  local f = assert(io.open(ruta, "r"))
  local ok, res = pcall(analizar, f:read("a"))
  f:close()
  if not ok then error(res, 0) end
  return res
end

La versión compatible es correcta pero frágil: cada retorno anticipado que añadas al cuerpo obliga a repetir el cierre, y basta olvidar uno para tener una fuga. La variable de cierre traslada esa garantía del programador al lenguaje, y es la razón por la que merece la pena exigir Lua 5.4 en proyectos que manejen recursos escasos.

Cuando falla el que maneja los fallos

flowchart TD
A[Error dentro del manejador de xpcall] --> B[No se vuelve a llamar al manejador]
B --> C[Se devuelve un estado especial y un mensaje fijo]
C --> D[Se pierde el diagnostico original]
E[Error dentro de un finalizador] --> F[Se convierte en aviso normalmente silenciado]
G[Error dentro de un cierre garantizado] --> H[Se propaga con normalidad]
I[Error dentro de una corrutina] --> J[Resume devuelve falso y el valor]
J --> K[El rastro debe pedirse sobre la corrutina antes de descartarla]

Un error nacido dentro del manejador de una llamada protegida con manejador no se maneja recursivamente: el intérprete corta la secuencia, devuelve un estado de error durante el manejo de errores y sustituye el diagnóstico por un mensaje fijo. Lo que se pierde no es el segundo error, es el primero, que era el importante. Por eso un manejador debe ser defensivo hasta la paranoia: nada de indexar campos sin comprobar, nada de concatenar valores que podrían no ser textuales, nada de llamar a código de la aplicación.

local function manejadorSeguro(err)
  local ok, texto = pcall(tostring, err)          -- tostring puede lanzar
  if not ok then texto = "error no representable" end
  local ok2, rastro = pcall(debug.traceback, texto, 2)
  return ok2 and rastro or texto
end

Los otros tres casos del diagrama completan el mapa. Un error dentro de un finalizador se convierte en un aviso, y el sistema de avisos nace apagado, de modo que puede estar fallando en cada ejecución sin que nadie lo note. Un error dentro de un cierre garantizado sí se propaga, porque ese código forma parte del flujo normal. Y un error dentro de una corrutina no cruza la frontera de la reanudación: se devuelve como valor, y si quieres el rastro tienes que pedirlo sobre el objeto de la corrutina antes de que se descarte, porque su pila es independiente de la tuya.