Fallar bien: la estrategia detrás del try/catch

Ya tienes la mecánica: throw, catch, errores propios. Pero un martillo no te hace carpintero. La pregunta difícil no es CÓMO atrapar, sino DÓNDE y CUÁNDO —y cuándo NO hacerlo. Esta lección es la que distingue el código que falla con dignidad del que esconde bugs bajo la alfombra.

Dos criaturas distintas con el mismo disfraz

Regla 1: atrapa en los bordes, no en cada esquina

El instinto novato es envolver cada línea en su try/catch. El resultado es código ilegible donde la lógica se ahoga entre redes. La estrategia madura: las funciones internas lanzan libremente; el catch vive UNA vez, en el borde —donde el error se convierte en algo para el usuario:

Mira qué limpias quedan parsearMonto, validarPositivo y registrar: sin una sola red, se leen como la receta que son. Toda la gestión de errores se concentra en manejarEnvio —el borde entre tu lógica y el mundo. Esa es la forma: lanzar profundo, atrapar en la superficie.

Regla 2: no atrapes lo que no sabes manejar

Un catch solo tiene sentido si vas a HACER algo útil con el error: mostrar un mensaje, reintentar, usar un valor por defecto. Si tu catch no sabe qué hacer, no lo atrapes —deja que suba a quien sí sepa. Atrapar para volver a lanzar el mismo error sin aportar nada solo agrega ruido:

La prueba del algodón: si borras un try/catch y no pierdes nada útil, sobraba. Atrapar solo para re-lanzar idéntico es ceremonia vacía. Atrapar para añadir contexto, reintentar o dar un plan B —eso sí gana su lugar.

Regla 3: mensajes que ayudan, no que asustan

Un error tiene DOS audiencias con necesidades opuestas. El desarrollador quiere el detalle técnico crudo (nombre de campo, valor, stack) para depurar. El usuario final quiere una frase humana y una salida —jamás un stack trace ni un undefined is not a function:

Mini-reto

Rediseña con estrategia: 1) toma tres funciones encadenadas (parsear → validar → calcular) donde las internas solo lanzan; 2) pon UN try/catch en el borde que las invoca; 3) en el catch, imprime dos cosas distintas: un console.error técnico (con error.name y el valor recibido) y un mensaje "de usuario" amable y sin jerga. Siente cómo la lógica interna respira sin redes.

Qué sigue

Hasta ahora tu única ventana al programa fue console.log. Es hora de conocer el resto de la caja de herramientas: console.table, .group, .error, .time, .assert y más —el instrumental completo del detective antes de entrar al arma definitiva, el debugger.