Aller au contenu principal

Introduction

Déclenchez des erreurs de test (404, 500) à la demande pour vérifier que vos pages d'erreur s'affichent correctement, et consultez le nombre de requêtes API du projet.

Plus d'informations sur l'interface utilisateur du module https://doc.oneentry.cloud/docs/category/system

🎯 Que fait ce module ?​

Le module System fournit des utilitaires au niveau du système. Il vous permet de tester la gestion des pages d'erreur - simuler des erreurs 404 et 500 pour vérifier que vos pages d'erreur s'affichent correctement avant que les utilisateurs ne rencontrent de réels problèmes - et il expose getApiStat() pour lire le nombre de requêtes API du projet.

Les méthodes d'erreur (test404, test500) déclenchent une redirection vers la page d'erreur correspondante afin que vous puissiez confirmer que votre gestion des erreurs est correctement mise en œuvre. Utilisez-les pendant le développement et les tests, pas dans le code de production.

🚀 Démarrage rapide​

Initialisez le module à partir de defineOneEntry :


const { System } = defineOneEntry(
  "your-project-url", {
    "token": "your-app-token"
  }
);

Lisez le nombre de requêtes API du projet :

// Returns an object with the API request count for the project.
const stat = await System.getApiStat();

console.log('API usage:', stat);

test404() et test500() lancent des erreurs intentionnellement pour exercer votre gestion des erreurs, donc appelez-les à l'intérieur d'un try/catch :

try {
  await System.test404();
} catch (error) {
  // Your 404 handling runs here.
  console.log('404 handler fired', error);
}

✨ Concepts clés​

Qu'est-ce que le module System ?​

Le module System fournit des utilitaires de test et de diagnostic :

  • Test d'erreur - Simulez des erreurs 404 / 500 avec test404() / test500()
  • Validation des pages d'erreur - Confirmez que vos pages d'erreur personnalisées s'affichent
  • Utilisation de l'API - Lisez le nombre de requêtes API du projet avec getApiStat()
  • Outil de développement - Utilisez les méthodes d'erreur pendant le développement/test, pas en production

Types d'erreurs​

Code d'erreurNomQuand cela se produitCas d'utilisation
404Non trouvéLa ressource demandée n'existe pasPage non trouvée, produit manquant
500Erreur interne du serveurUne erreur côté serveur s'est produiteÉchec de la base de données, erreur de code

Flux de travail de test​

1. Develop custom 404 and 500 pages
   ↓
2. Implement error handling (try/catch, error boundaries)
   ↓
3. Trigger errors with System.test404() / System.test500()
   ↓
4. Verify your error pages display correctly
   ↓
5. Remove the test calls before deploying to production

📋 Ce que vous devez savoir​

Les méthodes d'erreur sont uniquement pour les tests​

Utilisez test404() et test500() uniquement pendant le développement et les tests - elles lancent des erreurs pour exercer votre logique de gestion. Exécutez-les en développement/staging, et retirez les appels de test avant la production. Les véritables erreurs 404/500 doivent être gérées avec votre propre try/catch et des limites d'erreur.

La journalisation et la surveillance sont de votre responsabilité​

Le module System ne journalise ni ne surveille les erreurs. La journalisation et la surveillance se font dans votre propre application ou avec des outils tiers - utilisez les méthodes de test pour déclencher des erreurs afin de confirmer que votre suivi fonctionne.

Les pages d'erreur personnalisées sont à vous de créer​

Le module ne fait que déclencher des erreurs ; vous devez créer les pages 404 et 500 personnalisées ainsi que la logique de gestion dans votre application.

📊 Tableau de référence rapide​

MéthodeDescriptionLanceCas d'utilisation
test404()Simuler une erreur 404 Non TrouvéErreur 404Tester la page d'erreur 404
test500()Simuler une erreur 500 ServeurErreur 500Tester la page d'erreur 500
getApiStat()Obtenir le nombre de requêtes API—Surveiller l'utilisation de l'API

❓ Questions fréquentes (FAQ)​

Quand devrais-je utiliser les méthodes d'erreur ?​

Utilisez test404() et test500() uniquement pendant le développement et les tests pour vérifier que vos pages d'erreur fonctionnent correctement. Ne les utilisez jamais dans le code de production - ce sont uniquement des outils de test pour valider la gestion des erreurs.

Comment tester mes pages d'erreur personnalisées ?​

Appelez System.test404() ou System.test500() dans votre environnement de développement, à l'intérieur d'un try/catch. Ces méthodes lancent des erreurs, déclenchant votre logique de gestion des erreurs afin que vous puissiez vérifier que les pages d'erreur personnalisées s'affichent correctement.

Quelle est la différence entre test404() et test500() ?​

test404() simule une erreur "Non Trouvé" (la ressource n'existe pas), tandis que test500() simule une "Erreur Interne du Serveur" (échec côté serveur). Testez les deux pour vous assurer que tous les scénarios d'erreur sont correctement gérés.

Que retourne getApiStat() ?​

Il retourne un objet avec le nombre de requêtes API du projet, utile pour surveiller l'utilisation de l'API.

🎓 Meilleures pratiques​

  • Utilisez les méthodes d'erreur uniquement dans les environnements de test - Ne déclenchez jamais d'erreurs de test en production.
  • Enveloppez les appels de test dans un try/catch - Les deux test404() et test500() lancent des erreurs intentionnellement.
  • Implémentez des pages d'erreur personnalisées - Le module ne fait que déclencher des erreurs ; les pages sont à vous de les créer.
  • Vérifiez le suivi des erreurs - Utilisez les méthodes de test pour confirmer que votre surveillance/journalisation fonctionne.
  • Retirez les appels de test avant le déploiement - Nettoyez les appels test404() / test500() avant la production.

🔗 Documentation connexe​