Réponse.

Perl a été initialement conçu comme un langage de script pour l'administration système, donc le modèle traditionnel de gestion des erreurs était plus procédural. Cependant, avec le temps, le langage a introduit des techniques avancées de gestion des exceptions et des erreurs.

Historique de la question

Dans les premières versions de Perl, les erreurs étaient captées grâce aux valeurs de retour des fonctions et aux vérifications de la variable globale $!, et plus tard, des constructions eval (capture dynamique) ont été introduites, tandis que des modules comme Try::Tiny ont ajouté des modèles try-catch concis et sécurisés.

Problème

Le Perl standard n'a pas de syntaxe intégrée pour try-catch. Les erreurs peuvent survenir aussi bien dans le code Perl que dans des appels externes (par exemple, en ouvrant des fichiers). Si les erreurs ne sont pas gérées explicitement, le programme peut continuer à fonctionner dans un état imprévisible. Il est nécessaire de choisir judicieusement la technique d'interception des erreurs en fonction du contexte, de la complexité de l'application et des exigences en matière de fiabilité.

Solution

Pour intercepter les erreurs en Perl, on utilise la fonction eval, en enveloppant le code potentiellement dangereux dans un bloc et en analysant le contenu de $@ après l'exécution.
Pour créer ses propres erreurs, on utilise die. Une génération d'erreurs plus précise et le relancement d'exceptions déjà décrites se fait via le cadre sinon.
Pour un traitement des erreurs « humain », il est pratique d'utiliser des modules tiers (par exemple, Try::Tiny).

Exemple de code — traitement des erreurs via Try::Tiny :

use Try::Tiny;

try {
    open my $fh, '<', 'file.txt' or die "Impossible d'ouvrir le fichier : $!";
    while (<$fh>) {
        print $_;
    }
}
catch {
    warn "Une erreur est survenue : $_";
};

Caractéristiques clés :

Le mécanisme d'erreurs est asynchrone — les erreurs à l'intérieur de eval et try/catch ne modifient pas le flux d'exécution principal tant qu'elles ne sont pas traitées explicitement.
L'interception des erreurs est possible à différents niveaux — low-level die/warn/return ou high-level try/catch dans les modules.
Les modules permettent d'éviter les erreurs typiques avec eval, liées à la réécriture de $@ et aux pièges de portée.

Questions pièges.

Dans quel cas un bloc eval ne capturera-t-il pas une erreur système ?

Eval ne capture pas toujours l'erreur si un exit fatal se produit dans les bibliothèques C (par exemple, un SEGFAULT à partir du code XS). Eval ne fonctionne qu'avec les erreurs fatales de Perl, et non avec les plantages des extensions C.

Que se passe-t-il avec la variable $@ lors de blocs eval imbriqués ?

Si un eval appelle un autre eval, la valeur de $@ sera écrasée à la sortie de celui-ci. Il est donc important de sauvegarder $@ dans une variable séparée avant le prochain eval, afin de ne pas perdre l'erreur originale.

Pourquoi les modules auxiliaires comme Try::Tiny déclarent-ils la variable $@ localement dans catch/try ?

Parce que Perl réinitialise automatiquement $@ seulement lors d'une sortie réussie de try (eval). Un retour en cas d'erreur, next, last peut faire en sorte que $@ reste non nettoyé, et dans le code suivant, il y aura une "erreur fantôme". Les modules comme Try::Tiny créent une variable scope-local pour cela.

Exemple:

try {
    die "Boom!";
}
catch {
    print "Attrapé : $_
"; # $_ - piège d'erreur à l'intérieur de catch
};

Erreurs typiques et anti-modèles

Ignorer la valeur de $@ après eval (erreur non détectée)
Mutation de $@ entre plusieurs eval sans sauvegarde
Utilisation de die simple sans try/catch pour des opérations critiques
Absence de journalisation des erreurs
Tentative d'intercepter des erreurs non liées à Perl (par exemple, des signaux du système d'exploitation)

Exemple pratique

Cas négatif

Dans le gestionnaire d'exportation de données, une erreur de connexion à la BDD est capturée via eval, mais la valeur de $@ n'est pas sauvegardée, et aucune journalisation n'est effectuée. Lorsque dans le prochain eval une autre erreur est appelée, la première est complètement perdue.

Avantages :

Le code ne plante pas immédiatement en cas d'erreur, il continue de fonctionner.

Inconvénients :

Lors du débogage, il est impossible de comprendre pourquoi l'export ne fonctionne pas, il n'y a pas de message d'erreur.
Risque de doublons ou d'erreurs fausses.

Cas positif

Utilisation de Try::Tiny pour traiter des sections critiques, toutes les erreurs sont écrites dans un journal séparé, l'erreur originale est sauvegardée et correctement affichée à l'écran.