Les exceptions Java sont divisées en deux catégories: exception vérifiée et exception d'exécution. Les exceptions vérifiées sont des exceptions qui peuvent être traitées pendant la phase de compilation.
La différence et la connexion entre l'exception vérifiée et l'exception d'exécution
Classes d'exception courantes
Énumérez plusieurs exceptions courantes d'exécution:
Énumérez plusieurs exceptions non-runtime (exceptions vérifiées):
Erreur
L'erreur se réfère généralement aux problèmes liés aux machines virtuelles, telles que les accidents du système, les erreurs de machines virtuelles, les défaillances de liens dynamiques, etc. Cette erreur ne peut pas être récupérée ou ne peut pas être capturée, ce qui entraînera une interruption d'application. Habituellement, les applications ne peuvent pas gérer ces erreurs, donc le programme ne doit pas essayer d'utiliser Catch pour attraper l'objet d'erreur. Il n'est pas nécessaire de lancer un objet d'erreur lors de la définition d'une méthode.
Utilisation des exceptions vérifiées
Comme mentionné précédemment, vérifié doit être géré explicitement, sinon l'erreur de compilation sera signalée, comme la déclaration d'un flux d'entrée de fichier:
FileInputStream fis = new FileInputStream ("test.md");Ce code sera compilé avec une erreur
Type d'exception non perdue filenotfoundException
Par conséquent, il doit être géré explicitement, et il existe généralement deux façons de gérer les exceptions vérifiées:
Si vous savez comment le gérer, il est préférable d'utiliser Try ... Catch ... Block Processing:
// Exception vérifiée doit être gérée explicitement essayer {fileInputStream fis = new FileInputStream ("test.md");} catch (filenotFoundException e) {e.printStackTrace (); System.out.println ("Le fichier n'existe pas!");}Si vous ne savez pas comment y faire face, jetez-le dans la méthode et gérez-la par l'appelant précédent:
Public Static Void Main (String [] args) lève FileLoTFoundException {// Exception vérifiée doit être gérée explicitement // L'exception est jetée dans la méthode principale et remise au JVM pour le traitement. La méthode de la gestion des exceptions de JVM consiste à imprimer les informations de la pile de trace et à terminer le programme pour exécuter FileInputStream Fis = new FileInputStream ("test.md");} Utilisez un lancer pour lancer des exceptions par vous-même
Parfois, selon les besoins de l'entreprise, nous jetterons par nous-mêmes des exceptions dans le programme. Par exemple, si le contenu du fichier de lecture est vide, nous pensons que c'est une exception. À l'heure actuelle, nous pouvons utiliser le lancer pour lancer activement l'exception et l'attraper:
// Utilisez Throw pour lancer activement une exception essayez {fileInputStream fis = new FileInputStream ("test.md"); if (fis.read () == 0) {lancer une nouvelle ioException ("fichier vide"); }} catch (ioException e) {e.printStackTrace ();}Si Throw lance une exception d'exécution, le programme peut être pris avec Try ... Catch ... ou l'ignorer.
Traitement de la chaîne d'exception
Dans les applications réelles au niveau de l'entreprise, nous n'exposez souvent pas les exceptions sous-jacentes aux applications de niveau supérieur, telles que ne pas exposer les exceptions SQL à l'interface utilisateur. Premièrement, pour les utilisateurs, voir les exceptions SQL ne leur est pas utile, et deuxièmement, pour les utilisateurs malveillants, il n'est pas sûr d'exposer les exceptions sous-jacentes.
Alors, comment bloquer l'exception sous-jacente? La pratique habituelle est: le programme attrape d'abord l'exception originale, puis lance une nouvelle exception commerciale. La nouvelle exception commerciale contient des informations rapides à l'utilisateur. Cette façon de gérer devient la traduction des exceptions. Ce qui suit montre comment un programme qui crée un utilisateur bloque l'exception sous-jacente:
// démontre la chaîne d'exception et créer l'utilisateur public void CreateSubscriber (int subid) lève BusinessException {try {// Créer la logique de l'utilisateur ...} catch (exception e) {// Process et enregistrer l'exception originale ... // en tête d'une nouvelle exception commerciale New BusinessException ("La création de l'utilisateur a échoué"); }}Vous pouvez voir que le programme masque l'exception d'origine et ne fournit que les informations d'invite d'exception nécessaire vers le haut, qui peuvent garantir que l'exception sous-jacente ne sera pas étendue à la couche de présentation, qui est complètement conforme au principe d'encapsulation de l'objet.
Ce type de capture d'une exception, de lancement d'une autre exception et de sauvegarde des informations d'exception d'origine est un traitement de chaîne typique, qui est appelé le modèle de chaîne de responsabilité dans le modèle de conception.
Plusieurs suggestions d'utilisation des exceptions
Nous utilisons des exceptions pour atteindre plusieurs objectifs:
Pour répondre à ces objectifs, nous devons:
1. Ne pas utiliser ou compter sur lui: les exceptions sont très pratiques, mais n'utilisez pas la gestion des exceptions pour une logique normale, comme
// Code d'origine if (FileSize> 100) {sysotem.out.println ("Le fichier est trop grand, veuillez télécharger à nouveau"); Continuez;} // Changez pour utiliser l'exception si (FileSize> 100) {lancez une nouvelle exception ("Le fichier est trop grand, veuillez télécharger à nouveau");} // faire cela est évidemment irresponsable.