Réponse

En Perl, il existe des blocs spéciaux (BEGIN, CHECK, INIT, END) qui permettent de contrôler le moment de l'exécution du code :

• BEGIN { ... } — s'exécute immédiatement lors de la compilation du fichier (avant le code principal et avant le chargement des modules);
• CHECK { ... } — s'exécute après que tous les fichiers soient compilés, mais avant leur exécution (ce n'est pas supporté dans toutes les versions de Perl);
• INIT { ... } — s'exécute avant le début de l'exécution du code principal ("runtime");
• END { ... } — s'exécute après la fin du programme, à la sortie du script.

Ordre d'exécution :

1. BEGIN
2. Compilation du code
3. CHECK
4. INIT
5. Code principal
6. END

Exemple :

BEGIN { print "BEGIN exécuté
"; }
CHECK { print "CHECK exécuté
"; }
INIT { print "INIT exécuté
"; }
print "Code principal exécuté
";
END { print "END exécuté
"; }

Question piège

Le bloc BEGIN à l'intérieur d'un module peut-il influencer l'état global du programme si le module est inclus avec require, plutôt qu'avec use ?

Réponse et exemple :

Les blocs BEGIN s'exécutent lors de la compilation, donc ils ne s'exécuteront pas si le module est inclus via require (au moment de l'exécution, pas lors de la compilation), et non via use (s'exécute lors de la compilation du fichier incluant). Cela peut entraîner un comportement inattendu si l'initialisation repose sur BEGIN.

Exemples d'erreurs réelles dues à l'ignorance des subtilités du sujet

---

Histoire 1 : Dans un projet, BEGIN était utilisé pour initialiser des variables d'environnement, et le module était inclus via require — en conséquence, les variables n'ont pas été définies, ce qui a causé le chaos dans le chargement des configurations en production.

---

Histoire 2 : Lors de l'utilisation du bloc END pour fermer un descripteur de fichier, les arrêts implicites du processus n'étaient pas pris en compte ; parfois, le bloc END ne s'exécutait pas en raison d'une terminaison aberrante de l'interpréteur Perl, ce qui entraînait une perte de données dans les logs.

---

Histoire 3 : Les blocs CHECK étaient le seul endroit pour exécuter des tests de validité de l'environnement. L'utilisateur a exécuté le script dans une ancienne version de Perl, où il n'y avait pas de bloc CHECK, et les vérifications n'ont tout simplement pas eu lieu — des pannes critiques n'ont été observées qu'en production.