4dim / Notas
Un proveedor caído no es un error de programa
El servidor de correo está caído y la pantalla de «olvidé mi contraseña» se queda en blanco, aunque el enlace ya exista en la base. Una regla de una línea que cambia cómo se ve tu producto los días malos, y dónde está su límite.
La pantalla en blanco que no explica nada
Si tu software depende de algo de fuera —un modelo de inteligencia artificial, un servidor de correo, la API de Meta—, esta nota te propone una regla de una línea que cambia cómo se ve tu producto los días malos.
La escena es conocida. Alguien pide restablecer su contraseña. El servidor de correo está caído. La pantalla se queda en blanco o enseña «algo salió mal».
Lo que pasó por dentro fue esto: la función que manda el correo lanzó una excepción, la excepción subió, nadie la atrapó, y se llevó por delante la pantalla entera. Una pantalla que tenía perfecto derecho a existir: el enlace de restablecimiento ya está creado y guardado. Lo único que falló fue el mensajero.
Que el proveedor esté caído no es un error de programa. Es un hecho que hay que enseñar en pantalla.
La regla, en una línea
En nuestro código, ninguna función que hable con un sistema de fuera lanza por un fallo de ese sistema. Devuelven una de dos cosas: salió bien, o salió mal y aquí está el motivo.
Aplica igual en dos archivos que no se parecen en nada: el que habla con el modelo de lenguaje y el que manda correo. Es la misma frontera —algo que no controlamos— y por tanto la misma regla.
La distinción que la sostiene es esta: una excepción es para lo que no debería pasar. Un índice fuera de rango, un dato con la forma equivocada, una llamada con argumentos imposibles. Son fallos de programación, y lanzar está bien porque quien los arregla es quien escribe el código.
Que un proveedor externo esté caído sí debería pasar. Va a pasar. Está en el contrato implícito de depender de alguien. Tratarlo como una anomalía es lo que produce pantallas en blanco.
Lo que se gana: la salida a mano
La regla no es solo de cortesía con quien mira. Habilita algo que no existe cuando se lanza: el camino alternativo.
Volvamos a la contraseña. Si la función devuelve «no se pudo mandar», quien programó la pantalla puede decidir qué hacer. Y lo que hace es enseñar una respuesta igual, porque el enlace sigue existiendo en la base de datos y se le puede dar a la persona por otra vía.
Con una excepción no atrapada, esa opción no existe: el programa se fue antes de llegar a plantearla.
| El correo no sale y… | Qué ve la persona | Qué puede hacer el negocio |
|---|---|---|
| la función lanza | Pantalla rota | Nada: no hay pantalla |
| la función devuelve el fallo | Una respuesta clara | Pasar el enlace a mano |
«Sin configurar» tampoco es un fallo
La misma idea, llevada un paso más lejos y con una consecuencia práctica para cualquiera que instale software.
Nuestro sistema funcionó meses sin servidor de correo configurado, y tiene que seguir pudiendo. Cada camino que manda un correo tiene su salida a mano: el dueño copia el enlace de la invitación y lo pega en un WhatsApp.
Lo que hace la comprobación de «¿hay correo?» no es bloquear nada. Es dejar que la pantalla diga la verdad sobre cuál de los dos caminos está usando: «te mandamos un correo» o «cópiale este enlace».
Las dos frases son correctas. La que arruina la confianza es decir la primera cuando está pasando la segunda.
Dónde está el límite de la regla
Conviene decir dónde no aplica, porque llevada al extremo produce el problema contrario: código que nunca falla y nunca funciona.
Un fallo que sí debe romper con ruido es el de configuración equivocada que compromete algo. En el archivo que habla con el modelo hay un ejemplo: si alguien configura un modelo que no puede tocar datos de clientes, la llamada no cae al modelo por defecto. Se niega, y lo dice.
La diferencia es quién tiene que enterarse. Si el proveedor está caído, quien tiene que enterarse es la persona que está delante, con una frase clara. Si alguien configuró algo peligroso, quien tiene que enterarse es quien lo configuró, y para eso hace falta que no funcione.
Se es blando con lo que va a pasar y duro con lo que no debería poder pasar.
Qué hacer entonces
- Haz la lista de lo que depende de fuera. Correo, pagos, mensajería, inteligencia artificial, mapas. Esa lista es la lista de tus pantallas en blanco futuras.
- Apaga uno a propósito y mira qué pasa. Pon mal la contraseña del correo en un entorno de pruebas y pide restablecer la clave. Lo que veas es lo que verán tus clientes.
- Para cada dependencia, escribe la salida a mano. Si no hay ninguna, ese servicio es en realidad obligatorio y conviene saberlo.
- Que la pantalla diga qué camino usó. «Te mandamos un correo» y «cópiale este enlace» son las dos verdaderas; decir la primera cuando pasa la segunda no lo es.
- Deja que rompa lo que compromete algo. Ser blando con una configuración peligrosa es enseñar que se puede intentar.
Esta nota sale de nuestro trabajo en Software a medida.