Programmation Java: Throwing Errors - mannequins

Il est essentiel que votre code Java fasse tout son possible pour résoudre un problème. Cependant, il arrive que votre code ne dispose pas de suffisamment d'informations, de ressources, de droits ou d'autres conditions pour résoudre un problème.

Lorsque cela se produit, votre code génère une erreur en utilisant un objet d'exception. Le terme exception est approprié car il devrait être l'exception à la règle, plutôt que le premier acte que l'application effectue. Même dans ce cas, les applications rencontrent des erreurs nécessitant des mesures exceptionnelles, et les sections suivantes décrivent comment gérer ces types de situations.

Erreurs de lancement dans des conditions exceptionnelles

Pour la pratique, vous pouvez créer une application qui peut générer plusieurs types d'erreurs. Normalement, vous ne lanceriez pas une erreur si une valeur est dans la mauvaise plage - vous afficheriez un message directement à l'utilisateur à la place. Toutefois, vous pouvez créer un exemple qui montre comment lancer et intercepter une erreur à l'intérieur d'une méthode.

Transmission des erreurs à l'appelant

De nombreux exemples de code avec lesquels vous commencez commencent juste à arriver au point où vous appelez des méthodes de main (). La méthode main () est toujours le plus haut niveau de votre application. Lorsque vous appelez des méthodes, les méthodes que vous appelez forment des niveaux supplémentaires.

Par exemple, une méthode appelée de main () serait au deuxième niveau de votre application. Si cette méthode devait appeler une autre méthode, cette méthode serait au troisième niveau, et ainsi de suite. La plupart des applications sont composées de plusieurs niveaux d'appels.

En fait, quand vous voyez une exception à l'écran, elle affiche en fait une liste des méthodes qui ont appelé la méthode courante dans un format appelé la pile d'appel .

La pile d'appels est une liste de méthodes et l'ordre dans lequel elles sont appelées par d'autres méthodes. Connaître la pile d'appels peut vous aider à localiser la source d'une erreur potentielle quand cela ne se produit pas au niveau actuel de l'application.

Les erreurs de manipulation constituent un élément essentiel d'une bonne pratique de programmation. Si vous voulez des applications robustes qui ne se bloquent pas constamment, vous devez gérer correctement les erreurs. Cependant, essayer de gérer une erreur lorsque vous n'avez pas assez d'informations pour gérer cette erreur est également un problème.

Lorsque votre code tente de corriger une erreur à un niveau trop bas, il masque l'erreur à partir d'un niveau qui pourrait éventuellement la réparer. Oui, vous voulez corriger une erreur au niveau le plus bas possible, mais pas au prix d'une réparation qui pourrait finir par cacher quelque chose de plus sérieux.

Lorsque vous constatez qu'un niveau particulier d'une application ne dispose pas des ressources, informations, privilèges, accès utilisateur ou tout autre élément requis pour traiter une erreur, vous émettez une instruction throw avec l'objet exception approprié.Le niveau précédent de l'application recevra l'exception et déterminera si elle peut le gérer.

Cependant, si la méthode main () reçoit l'exception, vous devez déterminer ce qu'il faut faire de l'erreur, sinon l'application va planter. Il est généralement considéré comme une mauvaise pratique de programmation de laisser simplement l'application tomber en panne - vous devez trouver un moyen de gérer les erreurs que l'application rencontre.

Gestion des erreurs requises

Java fournit deux types d'exceptions: cochée (celles surveillées par le JRE) et non cochée (celles qui ne sont pas surveillées par le JRE). Vous avez la possibilité de gérer une exception non contrôlée. Cependant, Java vous oblige à gérer une exception vérifiée. Votre code ne sera même pas compilé si vous essayez d'utiliser une méthode associée à une exception vérifiée.

Une exception vérifiée est celle que le JRE est informé par la définition de classe à surveiller. Le JRE force l'utilisateur de la classe à gérer l'exception pour s'assurer que la classe fonctionne de manière fiable.

Toutes sortes de détails impairs sont associés aux exceptions cochées et non cochées. Un moyen facile de savoir si une exception est vérifiée est de connaître la classe parente. Toutes les exceptions qui sont sous-classées à partir des classes Error ou RuntimeException ne sont pas cochées - toutes les autres exceptions sont vérifiées.

La meilleure pratique consiste à gérer toutes les exceptions dans votre application, et vous n'aurez pas à vous soucier de savoir si une exception est cochée ou non. Un grand développeur gère toujours les erreurs potentielles - c'est le résultat.