3.5.Remontée des exceptions
Une exception levée est
propagée à la méthode appelante ;
l’exception remonte jusqu’à ce qu’elle
puisse être capturée ou qu’elle arrive au niveau
le plus haut, ce qui aura pour conséquence directe de
provoquer une erreur d’exécution.
Lorsqu’une première
méthode appelle une seconde méthode intégrée
dans une zone try/catch de cette première méthode,
et que cette seconde méthode appelle une troisième
méthode qui lève une exception, cette dernière
méthode ne possédant pas de bloc try/catch,
l’exception est renvoyée au niveau supérieur, à
savoir la seconde méthode qui elle non plus ne capture pas.
L’exception est finalement renvoyée à la première
méthode. La première méthode va capturer cette
exception grâce à sa zone try, puis elle va être
traitée dans sa zone catch.

Dans cet exemple, on laisse le code
appelant gérer l’exception que la méthode a
déclenchée. Pour cela on a défini que la méthode
pouvait lever une exception, le code pouvant déclencher
l’exception utilise le mot throws pour déclarer
l’exception. Dans ce cas la méthode n’a pas besoin
de gérer l’exception qu’elle a déclenchée.
Puisque certaines exceptions pourront
être susceptibles de remonter de très loin, il sera
intéressant d’être capable de déterminer
d’où ces exceptions ont été levées.
La méthode printStackTrace()
a pour but de récupérer la trace empilée de
l’exception. Cette trace empilée permet de retrouver la
méthode d’origine où a été levée
l’exception mais aussi permet de voir toutes les méthodes
qui ont suivi pour atteindre cette méthode initiale.
{
//
instructions pouvant générer une erreur
} (Exception e) {
e.printStackTrace(System.err);
}
Il
est possible d’indiquer plusieurs types d’exceptions en
séparant leurs noms par des virgules.
IOException, InterruptedException {
}
3.5.1.Modifier l’origine d’une
exception
Lorsqu’une exception est
détectée, l’interpréteur indique que cette
exception s’est produite dans la ligne du bloc try et
non dans la méthode ou l’exception s’est
réellement lancée. En effet le handler ne se préoccupe
ni de vérifier le contenu de l’exception ni sa
provenance.
Pour obtenir un résultat
différent, Java propose deux méthodes qui vont
permettre de modifier soit l’origine de l’exception soit
son type :
Afin de pouvoir retrouver l’origine
exacte ou le renvoi a été effectué, il faut
utiliser la méthode fillInStackTrace().
Une
autre façon de modifier l’exception est de changer son
type. Pour cela on devra avoir recours au sur-casting :
catch
(IndexOutOfBoundsException e) {
Sytem.err.println("Erreur");
throw
(RuntimeException)
e;
}
3.5.2.Le mot clé finally
Il est utilisé après un
bloc try/catch. Il délimite une ou plusieurs actions
importantes devant être exécutées même si
une exception venait à être déclenchée et
que le programme s'arrêtait.
try
{
//
code suceptible de déclencher une exception
}
catch
(Exception e) {
//
gestion de l'exception
}
finally
{
//
code toujours exécuté que l'exception ait été
déclenchée
//
ou non dans le bloc try
}
En effet, lorsqu'on a du ménage
à faire avant de quitter une méthode, pour éviter
la duplication de code dans chaque zone de catch, on utilise ce mot
clé (Exemple : ouverture d'un fichier devant être
refermé même si une erreur à été
rencontrée).
Si des instructions sont exécutées
dans le bloc catch, les instructions du bloc finally
seront exécutées après. Si le bloc catch
ne gère pas l’exception, le bloc finally va être
exécuté avant que l’exception ne soit remontée
à un niveau supérieur.
Enfin pour exécuter uniquement
des opérations de nettoyage, le bloc catch peut être
retiré et donc seuls les blocs try et finally
sont utilisés.
|