Les erreurs sont le fléau des utilisateurs et des programmeurs. Les développeurs ne veulent évidemment pas que leurs programmes tombent à chaque tour et les utilisateurs sont maintenant tellement habitués à avoir des erreurs dans les programmes qu'ils acceptent à contrecœur de payer le prix d'un logiciel qui contiendra presque certainement au moins une erreur. Java est conçu pour donner au programmeur une chance sportive de concevoir une application sans erreur. Il existe des exceptions dont le programmeur saura qu'elles sont possibles lorsqu'une application interagit avec une ressource ou un utilisateur et ces exceptions peuvent être gérées. Malheureusement, il existe des exceptions que le programmeur ne peut pas contrôler ou ignore tout simplement. En bref, toutes les exceptions ne sont pas créées égales et, par conséquent, il existe plusieurs types auxquels un programmeur doit penser.
Une exception est un événement qui empêche le programme de s'exécuter dans son exécution prévue. Il existe trois types d'exceptions: l'exception vérifiée, l'erreur et l'exception d'exécution.
Les exceptions vérifiées sont des exceptions auxquelles une application Java devrait pouvoir faire face. Par exemple, si une application lit des données à partir d'un fichier, elle doit pouvoir gérer le FileNotFoundException
. Après tout, rien ne garantit que le fichier attendu sera là où il est censé se trouver. Tout pourrait arriver sur le système de fichiers, dont une application n'aurait aucune idée.
Pour aller plus loin dans cet exemple. Disons que nous utilisons le FileReader
pour lire un fichier de caractères. Si vous regardez la définition du constructeur FileReader dans l'API Java, vous verrez sa signature de méthode:
FileReader public (String fileName) lève FileNotFoundException
Comme vous pouvez le voir, le constructeur déclare spécifiquement que le FileReader
constructeur peut lancer un FileNotFoundException
. Cela a du sens car il est fort probable que le nom de fichier
La chaîne se trompera de temps en temps. Regardez le code suivant:
public static void main (String [] args) FileReader fileInput = null; // Ouvrez le fichier d'entrée fileInput = new FileReader ("Untitled.txt");
Syntaxiquement, les instructions sont correctes mais ce code ne sera jamais compilé. Le compilateur connaît le FileReader
constructeur peut lancer un FileNotFoundException
et c'est au code appelant de gérer cette exception. Il y a deux choix - premièrement, nous pouvons transmettre l'exception de notre méthode en spécifiant un jette
clause aussi:
public static void main (String [] args) lève FileNotFoundException FileReader fileInput = null; // Ouvrez le fichier d'entrée fileInput = new FileReader ("Untitled.txt");
Ou nous pouvons réellement gérer à l'exception:
public static void main (String [] args) FileReader fileInput = null; essayez // Ouvrez le fichier d'entrée fileInput = new FileReader ("Untitled.txt"); catch (FileNotFoundException ex) // dire à l'utilisateur d'aller chercher le fichier
Les applications Java bien écrites devraient pouvoir faire face aux exceptions vérifiées.
Le deuxième type d'exception est connu sous le nom d'erreur. Lorsqu'une exception se produit, la JVM crée un objet d'exception. Ces objets dérivent tous de la Throwable
classe. le Throwable
la classe a deux sous-classes principales- Erreur
et Exception
. le Erreur
classe désigne une exception qu'une application ne sera probablement pas en mesure de traiter.
Ces exceptions sont considérées comme rares. Par exemple, la JVM peut manquer de ressources car le matériel n'est pas en mesure de faire face à tous les processus auxquels il doit faire face. Il est possible que l'application intercepte l'erreur pour avertir l'utilisateur, mais en règle générale, l'application devra se fermer jusqu'à ce que le problème sous-jacent soit résolu.
Une exception d'exécution se produit simplement parce que le programmeur a fait une erreur. Vous avez écrit le code, tout semble correct pour le compilateur et lorsque vous exécutez le code, il tombe car il a tenté d'accéder à un élément d'un tableau qui n'existe pas ou une erreur logique a provoqué l'appel d'une méthode avec une valeur nulle. Ou n'importe quel nombre d'erreurs qu'un programmeur peut faire. Mais ça va, nous repérons ces exceptions par des tests exhaustifs, à droite?