Discussion :

[Caxton]

Bonjour tout le monde,

Je viens une fois de plus vous demander de l'aide, des explications et des informations.

Je cherche à comprendre le fonctionnement du try/catch. Pourquoi me diriez-vous ? Et bien pour l'utilisé dans mes classes de façon optimisé et pratique. J'aimerais aussi ne pas me contenté de placé (lorsque une réponse se fait sur un forum) de codé sans savoir à quoi ça sert et comment ca s'utilise. En parallèle je suppose (mais je ne suis pas sûr de mon coup) que c'est utile et pratique et que je pourrait faire moult actions avec ce petit système.

J'aimerais, si c'est possible, profiter d'un peu de votre expérience pour comprendre. J'ai imaginé pour ce cas un simple exemple.

Exemple :
Mettons que je veuille accéder à un fichier exemple.txt placé sous /home/nom/test/exemple.txt et que celui-ci n'est pas disponible en droit comme en présence. Et bien j'aurais normalement droit à une belle erreur si ce n'est un BSOD sous windaube. Afin d'éviter cela, je me serais bien vue tester la présence mais dans un try/catch.

Je vous remercie des infos que vous m'apporterais sur le sujet.

[Astartee]

Tu nous demande un cours particulier, là...
Commence par faire lire les différentes informations disponibles sur la gestion des exceptions.

Le tutoriel de Sun :
http://java.sun.com/docs/books/tutor...al/exceptions/

Les ressources DVP :
La FAQ :
http://java.developpez.com/faq/java/?page=exception
Les tutos :
http://java.developpez.com/livres/ja...urs-exceptions
http://jmdoudoux.developpez.com/cour...exceptions.php
http://anisfrikha.developpez.com/tut...va/exceptions/
Quelques articles pour approfondir :
http://blog.developpez.com/adiguba/p...-performances/
http://blog.developpez.com/adiguba/p...ked-exception/
Quelques sujets du forum :
http://www.developpez.net/forums/d55...ry-catch-java/
http://www.developpez.net/forums/d56...-instructions/
http://www.developpez.net/forums/d89...tions-finally/
http://www.developpez.net/forums/d76...et-fin-compte/
http://www.developpez.net/forums/d93...catch-finally/


N'hésite pas à revenir si tu as une question plus précise

[Caxton]

En fait je voulais plus partir d'un cas concret et ensuite approfondir. Mais si c'est mieux de bûcher des milliers de pages pour comprendre, alors je ferais !

[thelvin]

Je pense que les quelques centaines de milliers de tutoriels sur le sujet se sont déjà posé la question de savoir par où commencer.

Maintenant, si par hasard il y a une question plus ciblée...

[Caxton]

Et bien pas particulièrement, hormis, peut-être, le fait de vouloir gérer des cas concrets.

Pour moi une classe toute bête contient des méthodes et des champs. Si par exemple on appelle un setter sans lui transmettre de valeurs alors qu'on en attends une, il se trouve que le try/catch permettrait de renvoyer une erreur.

C'est ce que j'ai compris.
Maintenant j'aimerais affiner cela afin de comprendre puis d'utiliser ce principe de codage pour que ma classe ne devienne pas instable inutilement.

Jusque la, je me contentais juste de codé en prenant en compte les erreurs si j'en voyais. Mais maintenant je travail plus en amont à faire de l' UML. On se rends compte de bien des choses !

Alors j'ai décidé d'afficher en clair dans mes programmes un retour d'informations en clair via un catch (si c'est la bonne démarche) afin que le programme se protège des erreurs humaines due au codage et due à l'utilisation. Dire que j'ai une question précise serais, à mon sens pas évident pour le moment. Il faut bien débuté par un bout et finir par un fonctionnement concret.

Maintenant c'est sur, que vue le nombre de réponses sur le sujet ( j'entends en cherchant sur le forum... ) fait mal, car pas ou peu adapté à l'apprentissage en amont. Je comptais alors plus m'orienter sur le cotés théorique de la démarche afin de savoir ce qui la déclenche, pourquoi, dans quels cas peut-on éviter que l'exception se déclenche, comment s'y prendre pour que le try/catch soit utile et non surcharger (au cas ou on code pour le fun plus compliqué que ce que ça ne doit) et enfin si on crée un bloc try/catch après tout c'est aussi pour faire un code propre et utilisable.

C'est donc pour ça qu'au début j'étais parti sur un exemple compréhensible par tous, afin d'en comprendre tout les différents mécanismes.

Mais c'est si compliqué; pas le code, de se comprendre par écrits.

[tchize_]

ta quesiton est vague. Le principe du try catch finally ca reste

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
try{
 // code qui pourrait déclencher une exception
 } catch (....){
 // traitement de certaines exceptions
} finally {
 // code toujours exécuté
}

Ce que tu met dans ton traitement dépendra de tes cas concret d'erreur. Si c'est une fichier inexistant tu peux retourner false dans ta méthode, tenter l'accès à un autre fichier, log l'erreur et interrompre le process, lancer un autre exception, ....

[Caxton]

Maintenant la question est : Les exceptions sont à écrire soi-même ou elles sont écrite par défaut quand on code auquel cas il faut avoir l'erreur à la compilation puis la gérer par un try/catch ?

[tchize_]

si tu veux lancer toi même des exceptions dans des cas d'erreur, il faut utiliserla commande throw. Exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
public void setX(int x){
    if(x<0)
        throw new IllegalArgumentException("x doit être supérieur à 0");
 ....
}

[Caxton]

Ok !
Mais alors ou se placerais le tray/catch ? Au moment d'nitialiser vers setX ou alors au retour ?

[tchize_]

en supposant que l'exception est lancée par setX, le try / catch se met soit dans l'appelant, soit dans n'importe quelle méthode appelant l'appelant, etc. Bref, à chaque niveau, tu as plusieurs possibilité:

1) gérer et rattraper le cas d'erreur
2) ne pas le gérer et remonter plus haut
3) attrapper l'exception et en faire remonter une autre (particulièrement courant lorsque l'on passe d'un niveau à l'autre de l'application, exemple lors de la liaison entre le GUI et le buisness logic)
Tout dépend de l'exception et d'à quel niveau tu veux la gérer. C'est donc du cas par cas.