Respuesta.

Perl fue diseñado inicialmente como un lenguaje de scripting para administración de sistemas, por lo que el modelo tradicional de manejo de errores era más procedural. Sin embargo, con el tiempo, el lenguaje ha incorporado técnicas avanzadas de manejo de excepciones y errores.

Historia de la pregunta

En las primeras versiones de Perl, los errores se capturaban a través de los valores de retorno de las funciones y comprobaciones de la variable global $!, más tarde aparecieron construcciones como eval (captura dinámica), y módulos como Try::Tiny añadieron patrones de try-catch concisos y seguros.

Problema

El Perl estándar no tiene sintaxis de try-catch incorporada. Los errores pueden ocurrir tanto en el código Perl como en llamadas externas (por ejemplo, al abrir archivos). Si no se manejan los errores explícitamente, el programa puede continuar su ejecución en un estado impredecible. Es necesario seleccionar adecuadamente la técnica de captura de errores según el contexto, la complejidad de la aplicación y los requisitos de confiabilidad.

Solución

Para capturar errores en Perl se utiliza la función eval, envolviendo el código potencialmente peligroso en un bloque y analizando el contenido de $@ después de la ejecución.
Para crear errores personalizados se utiliza die. La generación de errores más específica y la reactivación de excepciones ya descritas se realiza a través del marco sinon.
Para un manejo de errores "humano" es conveniente usar módulos de terceros (por ejemplo, Try::Tiny)

Ejemplo de código — manejo de errores a través de Try::Tiny:

use Try::Tiny;

try {
    open my $fh, '<', 'file.txt' or die "No puedo abrir el archivo: $!";
    while (<$fh>) {
        print $_;
    }
}
catch {
    warn "Ocurrió un error: $_";
};

Características clave:

El mecanismo de errores es asíncrono — los errores dentro de eval y try/catch no alteran el flujo principal de ejecución, hasta que se procesan explícitamente.
La captura de errores es posible a diferentes niveles — bajo nivel die/warn/return o alto nivel try/catch en módulos.
Los módulos permiten evitar errores típicos con eval, relacionados con la sobrescritura de $@ y trampas de ámbito.

Preguntas espinosas.

¿En qué caso un bloque eval no capturará un error de sistema?

Eval no siempre captura el error si dentro ocurre una salida fatal en bibliotecas C (por ejemplo, un SEGFAULT desde código XS). Eval trabaja solo con errores fatales de Perl, no con caídas de extensiones C.

¿Qué sucederá con la variable $@ en bloques eval anidados?

Si dentro de un eval se invoca otro eval, al salir de este el valor de $@ se sobrescribirá. Por lo tanto, después de cada eval es recomendable guardar $@ en una variable separada hasta el siguiente eval, para no perder el error original.

¿Para qué los módulos auxiliares como Try::Tiny declaran la variable $@ localmente dentro de catch/try?

Porque Perl limpia automáticamente $@ solo en una salida exitosa de try (eval). El retorno por error, next, last puede llevar a que $@ permanezca sin limpiar, y el siguiente código tendrá un error "fantasma". Módulos como Try::Tiny crean una variable local de ámbito específicamente para esto.

Ejemplo:

try {
    die "¡Boom!";
}
catch {
    print "Capturado: $_
"; # $_ - trampa de error dentro de catch
};

Errores típicos y anti-patrones

Ignorar el valor de $@ después de eval (error no detectado)
Mutación de $@ entre varios eval sin guardar
Uso de die simple sin try/catch para operaciones críticas
Ausencia de registro de errores
Intentar capturar errores que no corresponden a Perl (por ejemplo, señales del sistema operativo)

Ejemplos de la vida real

Caso negativo

En el manejador de exportación de datos, el error al conectarse a la base de datos se captura a través de eval, pero el valor de $@ no se guarda, y no se realiza el registro. Cuando en el siguiente eval ocurre otro error, el primero se pierde completamente.

Pros:

El código no falla de inmediato en caso de error, sigue funcionando.

Contras:

Durante la depuración es imposible entender por qué no funciona la exportación, no hay mensajes de error.
Pueden ocurrir errores duplicados o falsos.

Caso positivo

Uso de Try::Tiny para manejar secciones críticas, todos los errores se registran en un log separado, el error original se guarda y se muestra correctamente en pantalla.