Implémenter une gestion des erreurs robuste en Node.js
Créez une architecture de gestion des erreurs Node.js professionnelle avec classes d'erreurs custom, middleware centralisé et monitoring.
Coller dans votre IA
Collez ce prompt dans ChatGPT, Claude ou Gemini et personnalisez les variables entre crochets.
Tu es un expert Node.js spécialisé dans la création d'applications robustes et résilientes. Je dois implémenter une gestion des erreurs professionnelle dans mon application.
Contexte de l'application :
- Framework : [EX: Express 4, Fastify, Koa, NestJS]
- Type d'application : [EX: API REST, application web fullstack, microservice]
- Sources d'erreurs : [EX: base de données PostgreSQL, APIs tierces Stripe/Sendgrid, système de fichiers]
- Logging actuel : [EX: console.log, Winston, Pino]
- Monitoring : [EX: Sentry, Datadog, aucun]
Problèmes actuels :
[DÉCRIRE_LES_PROBLÈMES: ex. erreurs non capturées qui crashent l'app, pas de distinction erreur métier/technique, logs insuffisants]
Implémente une stratégie de gestion des erreurs complète :
- Hiérarchie de classes d'erreurs : crée une classe AppError de base et des classes spécialisées (ValidationError, NotFoundError, UnauthorizedError, DatabaseError, ExternalServiceError) avec codes d'erreur standardisés.
- Middleware de gestion des erreurs : middleware Express centralisé qui normalise toutes les erreurs, formate les réponses JSON et gère différemment les erreurs opérationnelles et les bugs.
- Capture des erreurs non gérées : gestion des process.on('uncaughtException') et process.on('unhandledRejection') avec graceful shutdown.
- Logging structuré : format JSON avec correlation ID, stack trace en développement uniquement, séparation des niveaux de log.
- Intégration monitoring : configuration Sentry ou équivalent avec contexte utilisateur et release tracking.
- Tests : tests unitaires pour la hiérarchie d'erreurs et le middleware.
Personnaliser ce prompt avec Léa
Léa réécrit ce prompt pour ton métier et ton objectif précis — 3 questions suffisent.
Pourquoi ce prompt fonctionne
<p>Ce prompt distingue intelligemment les erreurs opérationnelles (prévisibles, gérables : utilisateur non trouvé, validation échouée) des erreurs de programmation (bugs imprévus : undefined is not a function). Cette distinction est fondamentale pour décider de la stratégie de recovery : retry pour les premières, alert et redémarrage pour les secondes.</p><p>La création d'une hiérarchie de classes d'erreurs avec des codes standardisés est une pratique de développement professionnel qui permet aux clients de l'API de gérer les erreurs de manière programmatique plutôt que de parser des messages texte. C'est la base d'une API robuste.</p><p>L'inclusion de la gestion des uncaughtException et unhandledRejection avec graceful shutdown est souvent omise par les développeurs Node.js juniors, mais elle est critique en production pour éviter les états corrompus et garantir que les requêtes en cours se terminent proprement.</p>
Cas d'usage
Résultat attendu
Hiérarchie de classes d'erreurs, middleware Express, gestion des erreurs non capturées, configuration de logging et intégration monitoring.
Améliorez ce prompt
Passez ce prompt dans l'Optimiseur pour renforcer le contexte, les contraintes et le format attendu.
Améliore ce prompt avec l'OptimiseurCommentaires
- LéaIA
Ajoutez un champ `statusCode` à vos classes d'erreurs pour les mapper directement au middleware HTTP. Pour éviter les `unhandledRejection`, utilisez un pattern `Result` (soit `Ok`, soit `Err`) dans les appels aux services externes : cela rend les erreurs explicites et permet un retour structuré vers le middleware centralisé.
Termes du glossaire
📬 Recevez de nouveaux prompts chaque semaine
Rejoignez notre newsletter et ne manquez aucun prompt.
Pour aller plus loin
Prompts similaires
Prompt Perplexity pour créer une architecture logicielle
Perplexity se distingue comme un outil particulièrement puissant pour la conception d'architectures logicielles grâce à sa capacité à synthétiser des sources techniques récentes et vérifiées. Contrairement à un LLM classique qui s'appuie uniquement sur ses données d'entraînement, Perplexity interroge le web en temps réel pour intégrer les dernières bonnes pratiques, les patterns architecturaux émergents et les retours d'expérience de la communauté. Que vous conceviez une architecture microservices, un monolithe modulaire ou un système événementiel, un prompt bien structuré permet d'obtenir des recommandations contextualisées avec des sources vérifiables. L'enjeu est de fournir suffisamment de contexte métier et technique pour que Perplexity puisse croiser les informations pertinentes : stack technologique, contraintes de scalabilité, budget d'infrastructure et compétences de l'équipe. En formulant votre demande avec précision, vous transformez Perplexity en véritable architecte consultant capable de proposer des diagrammes de composants, des choix de technologies argumentés et des stratégies de déploiement adaptées à votre contexte spécifique.
Stratégie de backup Kubernetes
Plan de reprise d'activité pour Kubernetes
Adapter une API pour différents clients
Adapter les réponses API selon les besoins du client
Mettre en œuvre l'optimisation des coûts avec Terraform
Réduire les coûts d'infrastructure cloud