Table des matières:
Vidéo: APPRENDRE LE JAVA #13 - LES EXCEPTIONS 2024
Des erreurs dans les applications Java peuvent survenir à différents moments. Cependant, vous pouvez classifier globalement lorsqu'une erreur se produira dans deux catégories, au moment de la compilation et de l'exécution, comme décrit dans les sections suivantes.
Erreurs de compilation
Le compilateur convertit le code de votre application en code octet Java. Au cours de ce processus, il prend le code lisible par l'utilisateur que vous écrivez et le convertit en quelque chose que le Java Runtime Environment (JRE) comprend.
Pour effectuer ce processus, le compilateur doit analyser le code, ce qui signifie qu'il lit le code de manière à déterminer sans ambiguïté ce que l'application doit faire, Je veux qu'il le fasse, et comment vous voulez que la tâche soit accomplie. Si vous ne respectez pas les règles d'écriture de code non ambigu, le compilateur affiche un message d'erreur. Ce message est en fait une sorte d'exception.
Analyser signifie lire l'entrée que vous fournissez, comme du code sous une forme lisible par l'homme, et la transformer en quelque chose d'autre, comme le code octet Java. Une application peut également analyser l'entrée de l'utilisateur. Par exemple, un utilisateur peut taper une chaîne que votre code d'application transforme en un nombre.
L'analyse syntaxique consiste donc à lire un type d'entrée, à interpréter cette entrée d'une manière spécifique, puis à produire une sortie basée sur l'entrée interprétée. Un analyseur génère une erreur lorsque l'entrée n'est pas ce qu'elle attend.
Par exemple, si l'utilisateur entre une chaîne contenant la lettre C et que vous attendiez une chaîne contenant un nombre, tel que 123, l'analyseur génère une exception indiquant que l'entrée est incorrecte.
Les erreurs de compilation sont les plus faciles à gérer parce que le compilateur vous dit normalement ce qui ne va pas et où l'erreur s'est produite. Même si l'information n'est pas exacte, le compilateur vous amènera au moins à la bonne zone du code cassé afin que vous puissiez rechercher l'erreur qu'il contient.
Pour que tout le monde comprenne exactement comment le langage Java est supposé fonctionner, les développeurs en créent une spécification. Cette spécification inclut les éléments de langage dans un langage spécial appelé Backus-Naur Form (BNF). L'utilisation de BNF est une méthode extrêmement précise de description d'une langue, de sorte qu'il n'y a aucun risque d'erreur d'interprétation de la part de qui que ce soit.
Vous pouvez voir un exemple de BNF pour le langage Java au Département d'Informatique - Daimi. Ne vous inquiétez pas trop de pouvoir lire cette spécification. La plupart des développeurs n'apprennent jamais à interpréter la BNF pour les langages qu'ils utilisent - c'est le domaine des développeurs de compilateurs.
Erreurs d'exécution
Le compilateur Java ne trouve pas toutes les erreurs dans votre code. Si la forme du code est correcte (c'est-à-dire que vous n'avez commis aucune erreur en tapant les éléments qui créent l'application), le compilateur ne trouvera pas l'erreur.
Par exemple, si vous initialisez une valeur numérique à 5 au lieu de 4, le compilateur ne peut pas trouver l'erreur pour vous parce que le compilateur n'a aucune idée que vous vouliez réellement écrire 4. Ces types d'erreurs créent erreurs d'exécution - ces erreurs qui se produisent à un moment donné de l'exécution de l'application.
Des erreurs d'exécution peuvent survenir à tout moment. Certaines erreurs sont plus susceptibles de se produire à des moments précis. La liste suivante vous donne des idées sur les moments où les erreurs d'exécution sont susceptibles de se produire:
-
Initialisation: Lorsque l'application démarre - avant qu'elle ne présente une interface quelconque à l'utilisateur ou n'effectue aucun travail utile - elle passe par une phase d'initialisation. C'est lors de la définition d'une variable au type incorrect ou en essayant d'utiliser une variable avant de l'initialiser sera remarqué. De nombreuses erreurs liées aux ressources se produisent également lors de l'initialisation car la plupart des applications ouvrent les ressources requises pendant cette période.
-
Mode de fonctionnement: Après l'initialisation d'une application, celle-ci est en mode de fonctionnement. S'il a une interface utilisateur, il commence à interagir avec l'utilisateur. C'est le moment où l'entrée de l'utilisateur est la plus importante.
Vous trouverez également des variables initialisées de manière incorrecte à ce moment car l'utilisateur (ou le destinataire de la sortie de l'application, tel que le système) verra que la sortie est incorrecte. Les demandes d'utilisateur pour des ressources, telles qu'un fichier de données, créent également des erreurs pendant ce temps.
-
Traitement en arrière-plan: La plupart des erreurs de traitement en arrière-plan résultent de l'environnement (perte d'une connexion réseau), des ressources manquantes (fichier perdu), des variables initialisées incorrectement ou des erreurs dans l'application pour effectuer une tâche. Certaines tâches sont plus souvent exécutées en arrière-plan que d'autres.
Par exemple, l'impression d'un document ou le téléchargement de ressources à partir d'Internet sont généralement effectués en arrière-plan, tandis que l'utilisateur continue de travailler avec l'application au premier plan.
-
Arrêt: Lorsque l'utilisateur (y compris les comptes système) indique à l'application qu'il n'est plus nécessaire, l'application passe par une phase d'arrêt. Au cours de cette phase d'arrêt, l'application ferme les fichiers et exécute d'autres tâches d'entretien qui garantissent que l'application ne gâche pas le système d'exploitation.
Les erreurs les plus courantes pouvant survenir au cours de cette phase ne libèrent pas les ressources utilisées par votre application et ne sauvegardent pas les données sur le disque. Bien sûr, des erreurs de codage peuvent survenir à tout moment, et cette phase de fonctionnement ne fait pas exception. Vous pouvez dire à l'application de fermer cinq fichiers lorsque seulement quatre d'entre eux sont réellement ouverts.
Le JRE présente la plupart des erreurs d'exécution qu'il détecte comme des exceptions. Cependant, le JRE n'attrape pas toutes les erreurs dans votre application.Vous devez également regarder la sortie de votre application pour déterminer si la sortie correspond aux attentes que vous avez pour une entrée donnée.
En outre, il est important de vérifier l'état des ressources que vous utilisez pour vous assurer qu'elles ne sont pas endommagées d'une manière ou d'une autre. Par exemple, vous devez vous assurer que toutes les données que vous devez enregistrer dans un fichier se retrouvent réellement dans le fichier lorsque votre application s'arrête.
Java 8 met davantage l'accent sur la sécurité, ce qui signifie que vous verrez plus d'instances SecurityException pendant que vous travaillez avec votre application.
Voir une augmentation des exceptions de sécurité ne signifie pas que votre code est défectueux ou que Java 8 est rempli de bugs - cela signifie que Java 8 localise automatiquement et vous signale les problèmes qui pourraient causer des problèmes de sécurité.
La documentation SecurityException apparaît à Java. net. Bien sûr, vous voudrez savoir de quoi parle tout le brouhaha.