Discussion :

[tarpal]

Bonjour
Je suis toujours en apprentissage de Java...
J'ai un timer qui fonctionne parfaitement et donc voici le code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
package horloge;
public class TimerCounter 
{
	static Thread thread = new Thread();
	public static void main(String[] args) throws InterruptedException
	{
 
	for ( int i=3 ; i>=0 ; i--)
	    {
		Thread.sleep(1000);;
 
	    if (i==3)
	    		{
	    	    System.out.println(i+ "  :Première instruction");
	    		}
	    if (i==2)
	            {
	    	    System.out.println(i+ "  :Deuxième  instruction");
	            }
	    if (i==1)
                {
	            System.out.println(i+ "  :Troisième  instruction");
	            System.out.println( " c'est terminé ");
                }
	     }
    }
}

Mon problème c'est que je n'aime pas ce genre de programme, où tout est fait dedans.
J'aime bien avoir deux fichiers
Un Main
Une Class Timer
ça fait un bon moment que je tourne en rond à partir de ce code pour avoir un main séparé avec sa class associée.
Mon but final étant d'utiliser cette Class timer dans un autre programme.
Puis-je avoir un peu d'aide?
Merci à vous

[joel.drigo]

Salut,

Il est difficile de donner une recette toute faite de comment transformer un programme séquentiel comme le tien en classes. Tout dépend de ce qu'il fait, de ce qu'on veut pouvoir faire.
Normalement, on part plutôt sur les concepts de base, on apprend ce qu'est un objet, les concepts autour (héritage, polymorphisme, tout ça), on voit ce qu'on peut faire en terme de syntaxe Java, puis de base d'architecture (Design Pattern, SOLID, etc.), ce qui permet ensuite d'élaborer des architectures d'applications à partir des spécifications, et, ensuite, par habitude, de pouvoir refactoriser du code.

Avant de commencer de parler de ton en programme en particulier, suffisament limité qu'on puisse trouver une solution simple et directe, juste une chose : ta variable thread est totalement inutile. Tu peux déjà la supprimer.

Je dirais que le plus simple dans ton cas est de commencer déjà par extraire le code de la méthode de lancement. Deux solutions : mettre le code dans le constructeur, ou mettre le code dans une méthode. Personellement, je n'aime pas mettre un code "actif" dans le constructeur d'une classe. Le constructeur est fait pour construire : initialiser les variables, éventuellement charger des ressources, mais pas pour le code actif, même si ça fonctionne, et que, finalement, c'est plus simple en terme d'écritude de code.

Donc tout simplement, on part sur un canevas avec une méthode :

Code :

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

1
2
3
4
5
6
7
package horloge;
public class TimerCounter {
 
        public void run() {
        }
 
}

La méthode run() sera la méthode à appeler pour faire ce que tu veux que ça fasse, en l'occurence, ce que tu fais actuellement dans la méthode main(), donc tout simplement, copier/coller :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
package horloge;
public class TimerCounter {
 
 
        public void run() throws InterruptedException {
              for ( int i=3 ; i>=0 ; i--) {
                  Thread.sleep(1000);
 
                  if (i==3) {
	    	    System.out.println(i+ "  :Première instruction");
	    	  }
 	          if (i==2) {
	    	    System.out.println(i+ "  :Deuxième  instruction");
	          }
	          if (i==1) {
	            System.out.println(i+ "  :Troisième  instruction");
	            System.out.println( " c'est terminé ");
                 }
	     }
        }
 
 
}

Je passe sur la problématique du InterruptedException. C'est probablement prématuré à ton niveau.

Maintenant, il faut pouvoir, comme toujours, lancer le programme, donc avoir une méthode main quelque part. Tu peux la mettre dans la classe TimerCount, mais si tu tiens à la mettre absolument dans une autre classe, on peut imaginer quelque chose comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
package horloge;
public class Launcher {
 
        public static void main(String[] args) throws InterruptedException {
 
                TimerCounter timer = new TimerCounter(); // création d'une instance de classe TimerCounter
 
                timer.run(); // appel de la méthode run
 
        }
 
}

Tant que les 2 classes font parties du même package, c'est tout ce qu'il faut.

[tarpal]

Merci joel.drigo pour ta réponse (riche d'instruction pour moi )
Je vais essayer d'exploiter tout ce que je découvre dans ta réponse.
A+

[joel.drigo]

NB : tu l'auras sans doute corrigée toi-même, mais j'ai fait une petite inversion (entre les mots static et void, dans la signature de la méthode main) dans l'exemple de la classe Launcher, que j'ai corrigée dans le message depuis.

[tarpal]

Bonjour joel.drigo
J'ai fini d'exploiter tes explications :

ta variable thread est totalement inutile.

Je l'ai supprimé, et ça marche.
J'avais pris ce bout de code sur le Net et j'ai copié bêtement...
Je n'ai pas bien compris sur les tutos le Tread.
Si c'est trop long à expliquer, je lancerai un nouveau post sur le sujet.

donc avoir une méthode main quelque part

J'ai bien créé mon Main que j'ai appelé MainLauncher.
Quand je regarde le titre de mes class, j'aime bien repérer du premier coup mon Main.
J'ai donc mon nouveau code avec 2 fichiers : "MainLauncher" et "TimerCounter"
ça marche et je te remercie pour ton aide.

Je passe sur la problématique du InterruptedException.

J'avais commencé à travaillé sur cette instruction...
je l'avais trouvé quand je codais sur

Code :

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

Thread.sleep(1000);

quand je voulais faire une temporisation dans mon code.
Ici il se trouve dans :

Code :

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

public void run() throws InterruptedException

Ce code ne me plais pas car je ne le comprend pas.
Du coup j'ai une modification avec un code plus compréhensible pour moi...
Le voici :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
package carenoHorloge3;
 
public class MainLauncher 
{
    public static void main(String[] args) 
    		//throws InterruptedException 
    {
        TimerCounter3 timer = new TimerCounter3(); // création d'une instance de classe TimerCounter
 
        try {
			timer.run();
		    } 
        catch (InterruptedException e) 
            {
			// TODO Auto-generated catch block
			e.printStackTrace();
		    } // appel de la méthode run
 
    }
 
}

Est-ce la même chose ?
Encore Merci pour ton aide
A+

[joel.drigo]

Bonjour tarpal,

Je n'ai pas bien compris sur les tutos le Tread.

Tu parles des tutos de Developpez ?

J'ai bien créé mon Main que j'ai appelé MainLauncher.
Quand je regarde le titre de mes class, j'aime bien repérer du premier coup mon Main.
J'ai donc mon nouveau code avec 2 fichiers : "MainLauncher" et "TimerCounter"
ça marche et je te remercie pour ton aide.

[...]

Code :

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

public void run() throws InterruptedException

et le mettre dans "Tread.sleep" avec une instruction " Try / Catch"
[...]
Je n'ai pas compris la différence...

La différence entre le try/catch et le throws est :

• dans le cas du catch, tu attrapes l'exception : tu décides donc que c'est là qu'il faut la traiter
• le throws relance l'exception vers l'appelant : on ne sait pas comment la traiter, donc on la lance à l'appelant.

Dans le cas particulier de l'InterruptedException, le thread courant, qui était endormi le temps de la pause, a été réveillé prématurément. Il y a plusieurs façon de traiter l'exception :

1. la relancer par un throws, on ne sait pas quoi faire, on relance, l'appelant s'en chargera
2. on ne peut pas toujours relancer. Par exemple, si on utilise un Runnable, on n'a pas la possibilité de changer la signature de la méthode : on communique l'interruption à l'appelant via l'état interupted : Thread.currentThread().interrupt()
3. si le thread se termine juste après, ce n'est pas très important de s'en préoccuper, à fortiori si l'application s'arrête
4. le traitement peut être simplement de finir le thread aussi, tant qu'on est en haut de la pile d'appel, il y a rien au dessus qui pourrait traiter de tout manière, comme dans ce genre de cas :
   

   Code :

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

   1
   2
   3
   4
   5
   6
   7
   8
   9
   10
   11
   12
   13
   14
   15
   16
   public static void main(String[] args) {
          boolean loop=true; 
          System.out.println( "I'm alive!" );
          while(loop) {
              try {
                  Thread.sleep(1000);
                  System.out.println( "I'm still alive!" );
             }
             catch(InterruptedException e) {
                 loop=false; // on arrête la boucle et on laisse le programme se terminer tranquillement
             }
         }
          System.out.println( "Goodbye Cruel World" );
          System.out.println( "I'm leaving you today" );
    
   }

Dans ton cas, le plus important était que ça compile au moins. J'ai laissé le throws comme tu l'avais mis dans ton code. Le souci est juste que ça va afficher une stacktrace au cas où le thread est interrompu, et que ce n'est pas forcément ce qu'on veut (le fait qu'un thread soit interrompu n'est pas forcément un problème en soit, tant qu'on fait ce qu'on doit faire correctement (fermer correctement les ressources, s'assurer de la cohérence des résultats, des données en base, etc), on n'est pas toujours obligé d'avertir qui que ce soit qu'on n'a pas attendu aussi longtemps qu'on devait. On on peut simplifier on ne loguant que juste par un simple message, sans balancer une stacktrace de 500 lignes.

[tarpal]

Merci joel.drigo
Si j'ai bien compris :

le throws relance l'exception vers l'appelant : on ne sait pas comment la traiter, donc on la lance à l'appelant.

Aussi je fais appel à ton avis d'expert :
N'est-il pas dangereux de laisser le code gérer à sa guise l'InterruptedException ?

dans le cas du catch, tu attrapes l'exception : tu décides donc que c'est là qu'il faut la traiter

Ne serait-il pas plus sécurisant de le faire avec un "Try / Catch" ?
Au moins dans ce cas tu sais à quel endroit tu le fait.
Ton avis
A+

[joel.drigo]

Attention, lorsque je dis que je lance à l'appelant, je dis juste que je dis que c'est l'appelant qui va traiter l'exception, pas que ça va se faire tout seul et donc qu'on ne va rien maitriser.

L'endroit où on traite les exceptions dépend toujours de ce qu'on veut (enfin, je veux dire des spécifications). J'ai l'habitude de considérer quatre grands niveaux, du plus haut au plus bas :

1. Humain : l'humain s'en moque des exceptions, des problèmes techniques, tout ça : il veut que ça fonctionne tout seul un max, mais tolère que si vraiment exceptionnellement, on ne peut pas faire que ça marche tout seul, qu'on lui donne un message clair et compréhensible par un humain. Genre il veut charger un fichier qui n'existe pas, on lui dit que le fichier n'existe pas. On peut loguer le nom du fichier, comme ça s'il se plaint que le programme ne fonctionne pas, on peut toujours aller vérifier qu'il s'est gouré malgré le fait qu'il soutient mordicus que non, ou bien constater qu'il y a un souci avec les montages smb. En résumé, à ce niveau, il faut éviter que le programme échoue avec une stacktrace cabalistique dans une console, on "catch" un max.
2. Fonctionnel : on est a un niveau d'abstraction qui se fout du technique, une IOException, une NullPointerException, tout ça, c'est technique, pas fonctionnel. Données incomplètes. Le poids est négatif. Les données à traiter ne passe pas le test de conformité. Ça c'est fonctionnel. A ce niveau, on doit traiter les exceptions pour que les conséquences soient fonctionnelles : on convertit les exceptions en messages fonctionnels, en état fonctionnel, on ferme correctement ses ressources, on fait un rollback, on rend la main à l'utilisateur avec un état stable et cohérent, et on dit éventuellement qu'il y a eu un problème, sans rentrer dans les détails techniques plus qu'un éventuel laconique "Pour en savoir plus, consulter les logs". Cela suffira à l'utilisateur, au niveau au dessus, d'appeler son service technique en disant "j'ai un problème avec le fichier tartempion042, j'arrive pas à le traiter". Eventuellement, on peut notifier par mail un administrateur pour lui dire qu'un système s'est mis en rade. En revanche, si on retrouve une stacktrace dans le pdf d'une newsletter ça la fout mal. En résumé, à ce niveau, on doit pouvoir toujours réagir, au pire en loguant, mais en conservant des données cohérentes, en évitant de perdre les données : on "catch".
3. Technique classique : à ce niveau on est dans une zone un peu hybride : certaines exceptions peuvent être traitées, d'autres non. Si la connexion à un serveur échoue (SocketException, timeout exception, peu importe), on peut retenter 2 ou 3 fois de s'y connecter, éventuellement basculer sur une autre URL prévue en backup. Si un paramètre est manquant dans une configuration, on ne soulève pas une NullPointerException, on utilise une valeur par défaut, ou on s'arrête en douceur. Mais si un fichier est corrompu, on ne va pas prendre un autre fichier au hasard pour mener à terme le travail, on va le copier dans une zone de garbage, on va notifier (log, email, etc), et on va continuer avec les autres fichiers. Mais de temps à autre, on ne peut rien faire que lancer une exception : tu me demandes combien vaut une patate en me disant que 0 patates coûtent 10 euros, la seul solution que je connaisse c'est la division, et diviser par 0, je ne sais pas faire, donc ArithmeticException("divide by zero"). A ce niveau, des fois on catche, des fois on throws, des fois on fait les deux (on rethrow pas, mais on convertit l'exception)
4. Au niveau technique bas, au niveaux des API, du core, tout ça, en revanche, on fournit des services de base. On ne sait pas ce que ceux qui vont s'en servir veulent en faire, comment les appels vont être enchainés, dans quel cadre fonctionnel ils vont être utilisés, si l'exception est rédhibitore, ou bénigne. Et on a pas le savoir. On a juste à savoir ce qu'on peut faire ou pas avec ce qu'on a à faire. A ce niveau, on throws toujours, ou presque. On peut éventuellement utiliser des unchecked-exception pour ne pas contraindre l'appelant à mettre des try/catch ou throws.
   Par exemple, si on prend Integer.parseInt() : on sait que si on passe un texte qui n'est pas un nombre, il n'est pas possible de le convertir en int. Dans ce cas, ça soulève une NumberFormatException. Cela ne sait pas ce qu'on veut en faire de ce int. Un appelant lui le sait, peut-être l'appelant direct, peut-être 15 niveaux de stacktrace au-dessus, ou 150, mais il y en un): il sait si il doit afficher à l'utilisateur un message "Eh, banane, je t'ai demander le poids de pomme de terre et tu me réponds "je sais pas", je ne sais pas calculer le prix avec ça", il sait s'il doit prendre une valeur par défaut et laquelle, ou choisir une autre branche du programme, ou une autre formule de calcul, ou simplement sortir du programme gentillement avec un message "plus de données à traiter, au revoir et à la prochaine", etc. Au niveau supérieur, en revanche, on peut avoir une méthode qui traite de façon hybride un paramètre lu dans une config, si c'est du int, alors c'est la graisse de ma police, si c'est une String qui correspond à une valeur d'enum, genre BLACK ou LIGHT, je sais en déduire la valeur de la graisse, mais si c'est "ma grand-mère fait de bonnes tartes à la rhubarbe", je suis bien obligé de soulever une exception "UnknowValueForFontWeight", quoique, je peux aussi décider fonctionnellement que dans ce cas, on utilise une graisse de 400.
   En résumé à ce niveau, il vaut mieux faire throw/throws la plus par du temps, qui à encapsuler une exception plus basse dans une autre, comme cause.

[joel.drigo]

Tiens, pour illustrer, je tombe sur un cas pratique à l'instant. Je viens de modifier un producteur d'itérateur sur un tableau Excel, en POI 3.9/Java 1.6 (les POI récents fournissent déjà ça, mais pas cette ancienne version). La modification consiste à pouvoir indiquer à partir de quelle ligne on commence, et à partir de laquelle on s'arrête. De définir un intervalle de lignes quoi.

Si un appelant me demande d'itérer entre la ligne -5 et 25, sachant qu'il y en que 20. Dois-je silencieusement itérer de la ligne 1 à 20, ou dois-je soulever une exception pour dire à l'appelant qu'il n'y a pas de ligne -5 dans un feuille Excel, ou qu'il n'y en a que 20 lignes, donc 25 je ne peux pas. Ou dois-je simplement laisser POI planter mon programme avec une exception à lui. Est-ce que je dois contraindre tout le monde à catcher une exception explicitement, parce qu'il peut y avoir un ou deux pignoufs qui vont demander des lignes qui ne peuvent pas exister ?
Evidemment, avant, il n'y avait pas de question à se poser à ce sujet, on itèrait sur ce qui existait, de la ligne 1 à la dernière, point. Pas de raison d'avoir une exception.

[tarpal]

Merci joel.drigo pour ton suivi
Ta réponse me parait très complète et c'est tout à ton honneur...
Par contre le niveau de mes connaissances en programmation Java ne me permettra pas de tout comprendre.
Je vais donc retourner dans mon coin pour apprendre les Exceptions et savoir comment les comprendre.
Je pense qu'il faut mettre le sujet en résolu.
j'ouvrirai d'autres post pour plus de précision
A+