Bonjour.
C'est une application TODO faite avec Java + Spring, mais comme le traitement normal est terminé, je vais expliquer le traitement des exceptions ensuite.
1: [Comprendre les super bases] Une brève description de MVC 2: [Préparer un modèle] Je veux créer un modèle avec Spring Initializr et créer un monde Hello 3: [Connexion / Paramètres / Affichage des données avec MySQL] Enregistrer les données temporaires dans MySQL-> Tout obtenir-> Afficher en haut 4: [Fonction POST] Implémentation de la fonction de publication 5: [Fonction PATCH] Basculer l'affichage TODO 6: [Easy to use JpaRepository] Implémentation de la fonction de recherche [7: [Commun avec les fragments de modèle Thymeleaf] Créer un en-tête] (https://qiita.com/nomad_kartman/items/8c33eca2880c43a06e40) [8: [Fonction PUT] Implémentation de la fonction d'édition] (https://qiita.com/nomad_kartman/items/66578f3f91a422f9207d) [9: [Tweak] Trier l'affichage TODO dans l'ordre chronologique + Régler la date d'échéance à la date d'aujourd'hui] (https://qiita.com/nomad_kartman/items/5ee2b13a701cf3eaeb15) 10: [Gestion des exceptions avec ressort] Un bref résumé de la gestion des exceptions (ici et maintenant)
Une erreur est quelque chose que vous rencontrerez toujours lors de la programmation.
Implémentez quelque chose et démarrez l'application ... Écran d'erreur.
C'est une histoire courante de corriger cette erreur et de dire une autre erreur ...
L '«exception» de la gestion des exceptions est l'erreur ici.
En d'autres termes, ce qu'il faut faire quand un événement inattendu (= exception) se produit est la gestion des exceptions (manma).
Même si vous comprenez à quoi ressemble la gestion des exceptions en tant que concept, vous ne savez pas comment l'utiliser.
Alors, considérons d'abord les erreurs susceptibles de se produire avec cette application TODO!
La table TODO cette fois a été générée avec l'instruction de requête suivante! (Voir Créer une application TODO dans Java 3 Enregistrer les données temporaires dans MySQL-> Tout obtenir-> Afficher en haut)
CREATE TABLE `todo` (
`id` bigint(11) unsigned zerofill NOT NULL AUTO_INCREMENT COMMENT 'ID',
`title` varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT 'Titre',
`deadline` date NOT NULL COMMENT 'Date limite',
`status` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'statut',
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Date et heure de création',
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Mettre à jour la date et l'heure',
PRIMARY KEY (`id`),
UNIQUE KEY `title` (`title`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Ce à quoi je veux faire attention ici
`title` varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT 'Titre'
Cette phrase
La colonne de titre de TODO est varchar (30) '' et est
NOT NULL ''.
Cela signifie que le nombre maximum de caractères est de ** 30 caractères ** et que ** Null n'est pas autorisé **.
Par conséquent, même si vous demandez à enregistrer en SQL avec le titre de 30 caractères ou plus ou Null, cela échouera.
Si vous essayez d'enregistrer TODO avec 30 caractères ou plus, vous verrez cette page.
Dans la 5ème ligne à partir du haut
could not execute statement; SQL...
Est affiché, mais il est clairement indiqué que SQL n'a pas pu être exécuté.
Dans la deuxième ligne
This application has no explicit mapping for /error, so you are seeing this as a fallback.
"Vous n'avez pas défini (mappé) la page d'erreur à afficher par vous-même, alors affichons cette page!"
Est en train de dire.
Apparemment, il semble nécessaire de prendre des mesures pour éviter que cette erreur sur la 5ème ligne ne se produise et pour afficher la page d'erreur que vous avez définie vous-même.
L'explication ci-dessus n'est bien sûr qu'une des nombreuses erreurs possibles! J'ai donc essayé de résumer les parties correspondantes dans cette gestion des exceptions.
Maintenant, je voudrais expliquer pourquoi la gestion des exceptions est effectuée.
Je pense qu'il y en a d'autres, mais j'en ai en gros énuméré deux.
Si vous ne gérez pas les exceptions telles quelles, la page d'erreur en étiquette blanche sera toujours affichée chaque fois que quelque chose ne va pas avec l'application.
L'image ci-dessus n'en montre qu'une partie, mais en réalité, de mystérieuses phrases anglaises sont affichées dans une rangée.
Cela montre la cause de l'erreur et l'emplacement où l'erreur s'est produite, mais en les lisant, vous pouvez voir quelle est la structure de l'application.
Cela pourrait donner à une personne malveillante la possibilité d'attaquer!
Il est bon de ne pas afficher de telles phrases supplémentaires pour améliorer la sécurité de l'application.
C'est juste une question de montrer à l'utilisateur une page d'erreur de cauchemar, même pour le programmeur.
Par exemple, la page d'erreur que j'ai mentionnée plus tôt
Si vous êtes un programmeur, cette page peut vous donner une idée de la raison pour laquelle l'erreur s'est produite.
Les utilisateurs généraux ne pourront pas lire qu '"une erreur s'est produite car vous avez entré plus de 30 caractères".
Il est beaucoup plus aimable de donner un guide comme "Veuillez entrer TODO dans les 30 caractères" en lettres rouges plutôt qu'une page aussi effrayante.
J'ai brièvement résumé la gestion des exceptions, mais comment était-ce?
Vous pouvez rendre votre application sûre et pratique en gérant les exceptions.
Vous ne vous y habituerez peut-être pas au début, mais c'est une partie très importante de la production d'applications, vous pouvez donc prendre votre temps, alors étudions dur!
J'expliquerai comment écrire réellement la gestion des exceptions dans les articles suivants et suivants.
Recommended Posts