Envoyé par
ludovic01
Si j’ai bien compris, et si je veux coder proprement, je dois gérer mes exceptions en manuel avec un code du style :
1
2
3
4
5
6
7
8
9
| try{
...
}catch (GestionExceptuionX e ) { }
public gestionExeception extends Exception {
public GestionExecptionX(){
...
}
} |
Oui, c'est bien mieux de gérer ses propres exceptions avec des classes qui étendent Exception ou RuntimeException que de faire un throw new Exception. Cela permet d'avoir des catch dédiés et de traiter chaque cas d'exception. Attention toutefois à ne pas créer des exceptions qui existent déjà en standard : c'est bien mieux d'utiliser une exception standard en général, car elle aura du sens pour n'importe quel développeur. En particulier lorsqu'on fait des API. Par exemple IllegalArgumentException lorsqu'un argument intraitable est passé à une méthode, ou une ArtichmeticException lorsqu'il s'agit d'un calcul artihmetique infaisable, ou encore une NullPointerException pour un argument null, un IllegalStateException pour une appel de méthode qui ne peut être fait pour un état donné, UnsupportedOperationException pour une méthode non encore implémentée, IndexOutOFBoundException pour un dépassement d'index, NoSuchElementException lors qu'on ne peut produire d'élément (par exemple pour un pool qui atteint un max) etc.
Envoyé par
ludovic01
exxxxxx
Pour la solution du invokeLateret invokeAndWait, il me semblait bien avoir créé mes thread avec l'option runnable (bien que je ne saisisse pas encore bien la différence (mais cela fera peux être, voir surement l'objet d'un nouveau topic, que dis-je, d'un nouveau thread, lol)) avec la commande :
Thread t = new Thread(new Runnable(){
Le problème n'était pas dans la création même des threads, même dans leur usage dans ces circonstances là. Créer un thread avec un Runnable qui teste si on est dans l'EDT n'a pas de sens, non pas dans la façon de créer le thread, mais parce que le thread qu'on créé ne peut pas être l'EDT, donc inutile de tester s'il est. D'autre par, exécuter dans l'EDT un code qui doit être exécuté dans l'EDT lorsqu'on n'est pas dans l'EDT est bien ce qu'il faut faire, mais forcer son exécution dans un thread quelconque (donc pas l'EDT) lorsqu'on est justement dans l'EDT est un contresens.
Envoyé par
ludovic01
Aussi, si par exemple en plus de faire passer mon JPanel en jaune, je souhaite lui ajouter une image via ImageIcone, puis lui ajouter, je ne sais pas, un JtextField aussi. Dans ce cas-là, ne suis-je pas obligé de créer un objet via "ActionListener action = new ActionListener() {...}"en plein milieu de mon code pour le faire? Un peu comme dans mon exemple.
Pour ajouter des composants, on les ajoute c'est tout. Pas besoin en effet d'ActionListener. Dans le contexte, l'ActionListener est juste nécessaire à cause de l'usage du Timer. On utilisera aussi un ActionListener par exemple pour l'action sur un bouton, ou la validation de saisie dans un JTextField. Dans un process normal, par exemple, de création de JFrame, on a pas besoin d'ActionListener : on exécute une séquence d'instruction dans l'EDT et c'est tout. Si on doit déclencher quelque chose sur un évenement, on utilisera un ActionListener ou un autre type d'écouteur d''évenement selon les cas.
Envoyé par
ludovic01
exxxxxx
Enfin, une dernière question qui prouve mon "absolu debutance" (je sais cela n'existe pas dans le dico) Que signifie le "e" et plus précisément le "e ->"
Il s'agit d'une notation propre aux expressions lambda. Cela représente un paramètre.
Par exemple,
1
2
3
4
5
| ActionListener actionListener = new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.out.println("coucou);
}
}; |
Ceci est l'affectation d'une variable (actionListener) par une instance de classe anonyme implémentant l'interface ActionListener. Le e ici est un argument de la méthode actionPerformed, de type ActionEvent.
L'équivalent en expression lambda explicite de ce code est :
ActionListener actionListener = (ActionEvent e)-> System.out.println("coucou);
Comme il n'y a pas ambiguïté sur l'argument (le compilateur voit que la classe attendue doit implémenter ActionListener, donc une méthode actionPerformed() qui a un argument, de type ActionEvent, on peut simplifier cette écriture par :
ActionListener actionListener = e-> System.out.println("coucou);
Le e est toujours là pour indiquer qu'il y a bien un argument, et au besoin, si on veut l'utiliser dans le code de l'expression lambda il s'appelle e.
Cela devient plus clair si on a une interface fonctionnelle à 2 arguments. Par exemple java.util.Comparator. Mettons qu'on ait un tableau d'instance d'une classe Personne, qui a une méthode getNom() pour avoir le nom de la personne. On veut trier ce tableau de personne par ordre naturel (alphabétique) des noms de personne :
Arrays.sort(tableauDePersonnes, (p1,p2)-> p1.getNom().compareTo(p2.getNom()));
On a pas besoin de mettre le type de p1 et p2 (le compilateur "voit" qu'il s'agit d'un Comparator, et que le tableau étant un tableau de Personne, alors c'est que forcément le Comparator doit comparer des instances de Personne.
Demande d'explication sur un MouseListener
Répondre avec citation
La plupart des réponses à vos questions sont déjà dans les 
Partager