Un programme JavaScript peut se terminer sans bruit, ou au contraire laisser derrière lui des effets étranges qui déroutent l’utilisateur. Cette fin d’exécution mérite donc attention particulière.
Du navigateur à Node.js, chaque environnement impose ses règles, et un code négligent survit parfois en mémoire bien après l’intention initiale prévue. Un arrêt propre du script suppose alors un nettoyage des ressources précis, sinon des fuites subtiles s’accumulent, jusqu’à provoquer des comportements impossibles à diagnostiquer.
Ce qui se passe réellement quand un script atteint la fin
Quand le moteur JavaScript arrive au dernier caractère d’un fichier, le code synchrone a déjà été exécuté et les fonctions en cours se terminent les unes après les autres. Les variables locales sortent de portée, les closures gardent uniquement les références encore utilisées et le environnement d’exécution commence à relâcher ce qui n’est plus accessible. Le script global semble achevé, pourtant des opérations asynchrones peuvent encore être en file, en attente du bon moment pour s’exécuter.
Après cette phase, la pile d’appel peut se vider complètement tandis que la boucle d’événements inspecte les files de callbacks en attente. Elle déclenche les timers, les gestionnaires d’entrées utilisateur, puis traite les tâches microtask comme les promesses résolues avant de rendre la main.
- Le script global cesse quand plus aucune instruction synchrone ne reste à exécuter.
- Les callbacks, timers et promesses résolues continuent tant qu’ils disposent de références actives.
- Le moteur clôt le programme lorsque plus aucune tâche asynchrone ne maintient le runtime éveillé.
Arrêter un traitement côté navigateur sans bloquer l’interface
Un traitement intensif lancé sur le thread principal peut figer toute l’application web, au point de stopper les clics ou de retarder les réponses visuelles. Une boucle de calcul mal conçue garde le processeur occupé sans pause, et chaque événement utilisateur accumulé attend que le JavaScript libère brièvement la main pour être pris en compte par l’interface.
Pour préserver la fluidité, un long traitement se découpe en fragments exécutés de manière asynchrone à l’aide de setTimeout ou requestIdleCallback. Ce découpage en plusieurs tâches laisse passer le rendu du navigateur, facilite le rafraîchissement de l’ui et coopère avec une future annulation via abortcontroller déclenchée par l’utilisateur.
- Fractionner un algorithme lourd en lots planifiés avec
setTimeoutlimite les blocages perceptibles. - Appeler
requestAnimationFrameaide à aligner le travail sur les mises à jour visuelles. - Un signal d’
AbortControllermet fin proprement aux requêtes ou calculs devenus inutiles.
Fin de programme en node.js : fermeture des ressources et du processus
Quand un programme Node.js parvient en fin de traitement, le processus se termine dès que la boucle d’événements n’a plus de tâches planifiées. Le système libère la mémoire et signale la fin du processus au système d’exploitation hôte. Un script CLI qui ne garde ni serveur HTTP ni timer actif peut donc s’arrêter naturellement, sans appel explicite vers une API de sortie. Pour contrôler davantage le moment de l’arrêt, il est possible d’utiliser process.exit avec un code numérique, par exemple process.exit(0) pour marquer réussite. Les événements beforeexit offrent en complément l’occasion d’exécuter un morceau de code avant que Node ne quitte réellement.
Pour un serveur Node, la sortie propre consiste à laisser s’achever les requêtes actives puis à libérer chaque ressource. Une coordination claire orchestre la fermeture des connexions, la fin de stream et la clôture des fichiers.
process.on('beforeExit', (code) => {
console.log('Nettoyage avant sortie, code :', code);
});
process.on('SIGINT', async () => {
await server.close();
await db.close();
process.exit(0);
}); - Arrêter les serveurs HTTP ou HTTPS avec
server.close()pour terminer les requêtes en cours. - Clore les clients de base de données (par exemple
pool.end()pour PostgreSQL ouclient.close()pour MongoDB). - Supprimer les timers et intervals, afin de vider complètement la boucle d’événements Node.js.
- Intercepter les signaux système (
SIGINT,SIGTERM) et déclencher une procédure de sortie contrôlée.
Gérer les erreurs pour sortir proprement, même en asynchrone
Un programme JavaScript qui se termine sans message d’erreur renvoie une impression de fiabilité, même lorsqu’il a rencontré des problèmes internes. La première étape consiste à organiser la gestion d’exceptions autour des zones sensibles, par exemple la lecture de fichiers ou les accès à une base de données. Les blocs try { ... } catch (err) { ... } demeurent encore très utiles pour le code synchrone, mais il reste judicieux de les compléter avec un try catch async, en associant systématiquement await à des promesses susceptibles d’échouer.
Pour les opérations asynchrones, la surveillance des événements unhandledRejection et uncaughtException réduit les arrêts brutaux du processus. Une approche structurée du rejet de promesse et de la propagation d’erreur vers un gestionnaire central permet de consigner chaque incident et de clôturer proprement le programme.
async function main() {
try {
await runJob();
} catch (err) {
logger.error('Erreur fatale', err);
await cleanup();
process.exit(1);
}
}
process.on('unhandledRejection', async (reason) => {
logger.error('Rejet de promesse non géré', reason);
await cleanup();
process.exit(1);
}); | Type de problème | Mécanisme Node.js | Stratégie de terminaison |
|---|---|---|
| Erreur synchrone dans une fonction | Exception classique (throw) | Encadrer le code avec try/catch et retourner un code de sortie adapté |
Promesse rejetée avec await | Exception capturable dans la fonction async | Gérer dans un bloc try/catch asynchrone et déclencher le nettoyage |
| Promesse rejetée sans gestion locale | Événement unhandledRejection | Enregistrer, nettoyer les ressources puis terminer le processus avec process.exit(1) |
Annulation et nettoyage : timers, listeners, streams, connexions
Quand un script JavaScript touche à sa fin, des tâches planifiées encore actives peuvent continuer à tourner et empêcher la boucle d’événements de se clôturer. Les timers créés par setTimeout ou setInterval gagnent à être stoppés à l’aide de clearTimeout et clearInterval dès que leur travail est terminé. Vous pouvez centraliser ces identifiants dans un tableau pour les arrêter tous dans une même phase de nettoyage.
Pour vos interactions utilisateur, les écouteurs ajoutés avec addEventListener devraient disposer d’un réel désabonnement d’événements afin d’éviter des callbacks déclenchés sur des éléments déjà retirés du DOM. Les connexions réseau méritent le même soin : une fermeture de socket explicite coupe la liaison, tandis qu’une authentique libération de mémoire suit, grâce aux références supprimées et aux flux clôturés, ce qui facilite un arrêt silencieux du programme.
const timers = [];
timers.push(setTimeout(task, 5000));
function stopAll() {
timers.forEach((id) => clearTimeout(id));
}
- Répertorier tous les timers créés dans une structure dédiée pour les annuler facilement.
- Prévoir une fonction de nettoyage qui retire les écouteurs et ferme les flux ouverts.
- Terminer explicitement les connexions réseau avant la fin du script ou du processus.
- Surveiller les fuites de ressources lors des tests de longévité de l’application.
Codes de sortie, logs et messages : finir en laissant une trace utile
Dans un programme Node.js, la façon dont le processus se termine raconte déjà quelque chose sur ce qui vient de se produire. Un code de sortie unix égal à 0 signale un déroulement réussi, tandis qu’une valeur non nulle indique un problème détecté. Vous pouvez fixer ce code via process.exitCode ou appeler explicitement process.exit() à la fin de votre chaîne de promesses ou de vos callbacks.
Les messages produits pendant cette phase de clôture gagnent à être structurés par une véritable journalisation applicative, qui distingue les flux stderr et stdout plutôt que de tout envoyer avec console.log. Un court extrait comme celui‑ci suffit pour tracer un succès ou un échec :
console.log('Traitement terminé avec succès');
console.error('Erreur détectée', err);
process.exitCode = err ? 1 : 0; - Adopter une convention de codes de sortie cohérente avec les outils d’orchestration utilisés.
- Envoyer les informations métier vers la sortie standard et les anomalies vers la sortie d’erreur.
- Inclure des identifiants de requête ou de tâche dans les messages pour faciliter les corrélations.
- Archiver ou agréger les logs pour reconstituer le déroulement d’un traitement passé.
Vérifier que le programme se termine bien : tests et signaux
Un programme JavaScript peut cesser de tourner sans hurler d’erreur et pourtant laisser derrière lui des ports ouverts ou des fichiers verrouillés. Pour débusquer ces sorties incomplètes, des tests d’intégration complètent les tests unitaires en jouant le cycle complet démarrage, traitement, extinction, en déclenchant systématiquement vos hooks de terminaison afin de vérifier que le nettoyage mémoire, les fermetures de sockets et la libération de verrous se produisent.
Sous Node.js, les scripts vivent dans un processus lié au système d’exploitation, qui peut décider à tout moment de leur demander une sortie propre. Un terminal envoie parfois un signal SIGINT, ou un orchestrateur déclenche un arrêt via SIGTERM ; vos gestionnaires process.on() devraient alors fermer serveurs, connexions et flux avant l’appel final à process.exit.
- Contrôler que les tests automatisés couvrent bien le scénario de fin de vie du processus.
- Observer les logs produits juste avant la fermeture des serveurs et des connexions.
- Simuler l’envoi de signaux système pour vérifier le comportement en conditions réelles.
- Comparer les ressources ouvertes avant et après l’exécution complète du script.
process.on('SIGINT', () => {
console.log('Interruption reçue, arrêt en cours...');
server.close(() => process.exit(0));
});
process.on('SIGTERM', () => {
console.log('Arrêt demandé par le système');
server.close(() => process.exit(0));
});