
FAQ JavaConsultez toutes les FAQ
Nombre d'auteurs : 53, nombre de questions : 231, dernière mise à jour : 7 juin 2009
Sommaire→Le développement→Les erreurs et exceptionsQu'est qu'une exception ?
En Java, les erreurs sont gérées à travers des exceptions qui sont levées par exemple lorsqu'une méthode ne peut pas accomplir correctement son travail. Le compilateur ne laisse pas le développeur ignorer ces exceptions potentielles, chaque source d'erreur doit être traitée.
Traiter une exception :
Pour pouvoir traiter ces exceptions il faut utiliser une succession try/catch (essaye/attrape).
try {
/** ... mes instructions */
} catch (mon_type_d_Exception e) {
/** ... mon traitement si cette erreur intervient */
} catch (un_autre_Exception e) {
/** ... */
}
La "lancer" vers les méthodes appelantes :
Il est toujours préférable de traiter les exceptions au plus tôt pour préserver la lisibilité du code. Néanmoins, l'exception levée présente parfois un intérêt non négligeable pour la méthode appelante. En effet, si votre méthode courante permet de parser un fichier texte, il peut être utile pour la méthode appelante de savoir que le traitement n'a pas eu lieu, et pourquoi celui-ci n'a pas eu lieu. Un fichier manquant ne se traite pas de la même manière qu'un fichier corrompu ! Afin de lancer une exception vers la méthode appelante, il suffit de prévenir dès la déclaration :
public int maMethode() throws UneException, UneAutre, ...
Utiliser une exception qu'il n'est pas nécessaire d'attraper :
Si vous définissez vos propres exceptions, il peut arriver que vous soyez géné par l'obligation systématique de les "attraper". Certaines exceptions n'ont pas besoin d'être attrapées à la compilation, mais interrompent le déroulement de votre méthode, et de sa pile d'appel, tout en laissant une trace de son passage dans les fichiers de log. Ce type d'exception descend exclusivement de RuntimeException.
L'exception 'NullPointer' est levée lorsque l'application essaye d'utiliser null alors qu'une instance d'un objet est requis. Cela inclut :
- l'appel d'une méthode sur un objet null
- La lecture ou la modification d'un champ d'un objet null
- Demander la longueur de null comme s'il sagissait d'un objet
- La lecture ou la modification d'une case d'un tableau null
- Lever une exception null
Cette exception est levée à chaque utilisation incorrecte d'un objet null.
Cette exception peut être levée principalement par trois méthodes :
- La méthode forName de la classe Class.
- La méthode findSystemClass de la classe ClassLoader .
- La méthode loadClass de la classe ClassLoader.
Cette exception peut indiquer deux choses:
- Soit que votre CLASSPATH est mal configuré.
- Soit que les droits du fichier jar ou du fichier class ne permettent pas la lecture de celui-ci pour l'utilisateur courant.
Vérifiez que vos librairies externes sont bien référencées dans le CLASSPATH. Pour mettre une librairie (jar) dans le CLASSPATH vous pouvez la placer dans le répertoire JAVA_HOME/jre/lib/ext. Une seconde possibilité est de définir le CLASSPATH lors du lancement de la commande java (-cp).
Si vous utilisez un jar, vous devez référencer les librairies extérieures dans le manifeste (cf Comment créer un jar exécutable ? ).
Si votre CLASSPATH est correct, vérifiez alors les droits de vos fichiers, vous devez disposer au moins des droits en lecture.
Cette exception est levée lorsque l'on essaie d'accéder à une case d'un tableau qui n'existe pas.
Il faut avant tout vérifier à la ligne indiquée(dans le stackTrace) qu'on ne tente pas d'accès à une case inexistante (X).
Exemple :
int [] monTab=new int[20]; // creation d'un tableau de taille 20
for(int i=0;i<20;i++) {
tab[i]=i; // on le remplit
}
System.out.println(tab[20]); // on accede a la case 21 en voulant acceder à la case 20...
Le plus fréquemment, cette erreur vient du fait qu'on essaie d'acéder à la dernière case du tableau sans prendre en compte le fait que le tableau commence à l'index 0 et non pas un comme on pourrait le croire.
Le SecurityManager lève ce genre d'exception quand vous tentez d'accèder à des ressources protégées.
Cela peut être le cas pour les Applets, par exemple. Celles-ci doivent être signées pour pouvoir accèder aux ressources de la machine cliente (Système de fichiers, classe Robot, etc.). Vous pouvez aussi éditer votre fichier java.policy pour régler ces droits d'accès.
Regardez :
L'erreur java.lang.OutOfMemoryError est levée lorsque la JVM (la machine virtuelle Java) ne peut plus allouer de mémoire pour un Objet. Le GarbageCollector ne peut plus en liberer.
Une possibilité est d'allouer plus de mémoire au lancement de la JVM avec l'option -Xmsn. Vous pouvez aussi fixer la taille maximale de la mémoire avec l'option -Xmxn. Ou n indique la mémoire initiale disponible. Les valeurs par défaut sont respectivement de 2MB et 64 MB.
Voici un exemple de notation :
java -Xms6291456
// 6291456 bytes
java -Xms6144k
//6144 kilo
java -Xms6m
//6 méga
Dans une application graphique certaines exceptions se déclenchent depuis le thread dédié à l'affichage.
Il n'est pas possible d'intercepter ces exceptions avec un bloc try/catch classique.
Il est possible d'enregistrer une classe qui sera chargée de gérer ses erreurs.
Pour ce faire la propriété système sun.awt.exception.handler doit contenir le nom complet d'une classe ayant une méthode handle().
Cela peut être fait en passant l'option "-Dsun.awt.exception.handler=..." à la machine virtuelle ou par le biais de la méthode System.setProperty()
A chaque exception non interceptée, une nouvelle instance de cette classe est créée (il faut un constructeur vide) et la méthode handle() est appelée.
Cela ne fonctionne pas avec Java 5.0.
Dans le cadre de Java 5.0 on peut utiliser les UncaughtExceptionHandler avec la méthode Thread.setDefaultUncaughtExceptionHandler() (voir avec setUncaughtExceptionHandler() afin de l'effectuer thread par thread...)
Cette solution est nettement plus propre mais malheureusement elle neccessite une JVM 5.0.


















