Discussion :

[sabrinabest]

Bonjour,

J'aimerais connaître la syntaxe de "goto" en Java ?

Merci d'avance pour votre aide.

[adiGuba]

Salut,

Il n'y en a pas... Et tu ne devrait pas en avoir besoin

Le goto c'est le mal

a++

[OButterlin]

Le goto c'est le mal

adiGuba (Bush ???)

Pour le reste, il a raison...

[deltree]

Noter que c'est un mot-clef réservé, qu'il ne faut pas l'utiliser, et qu'il n'a jamais été utilisé (en java 1.2 du moins)

Il passe en "gras" sous Eclipse, et appeler une fonction ou une variable goto planterait à la compilation.

[Fifan31]

Noter que c'est un mot-clef réservé, qu'il ne faut pas l'utiliser, et qu'il n'a jamais été utilisé (en java 1.2 du moins)

Il passe en "gras" sous Eclipse, et appeler une fonction ou une variable goto planterait à la compilation.

Justement, 'goto' a été défini comme mot-clé pour qu'il soit réservé et surtout pour qu'il ne soit pas utilisé.
Avec une conception objet correcte, il n'y a pas besoin d'utiliser de 'goto'. Il "s'uffit" d'appeller la méthode adéquate.

[bulbo]

Par contre il y a moyen de sauter a un label défini au niveau d'une boucle, parfois utile pour 'breaker' ou 'continuer' alors qu'il y a des boucles imbriquées.

Code :

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

1
2
3
4
5
6
7
8
9
MonLabel: while (true)
{
  //...
  for ( ... )
  {
    //...
    continue MonLabel;
  }
}

Bulbo

[OButterlin]

On peut faire ça sans etiquette aussi...

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
 
...
while (true)
{
   if ( ! maBoucleImbriqueeDitDeContinuer() ) break;
}
...
 
public boolean maBoucleImbriqueeDitDeContinuer()
{
   for (...)
   {
       if ( conditionArret ) return false;
   }
   return true;
}

Ou utiliser judiscieusement une exception pour sortir d'une pile de boucle...

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
 
try
{
   while (true)
   {
      for (...)
      {
         throw new StopIterate();
      }
   }
}
catch (StopIterate s)
{
   // A priori, on ne fait rien
}

Bref, il y a de quoi faire sans goto...

[bulbo]

Oui mais bonjour la lisibilité, si c'est pour refaire ce que fait cette instruction pour respecter a la lettre le mantra " le goto saymal" je vois pas trop l'intérêt.

De toute façon le besoin de cette écriture se rencontre rarement et elle couvre parfois des cas particuliers que ta méthode ne facilitera pas ..

Bulbo

[Laurent.B]

Perso, je dirais que sortir avec une exception c'est super cracra !! et consommateur de ressources.

[denisC]

Perso, je dirais que sortir avec une exception c'est super cracra !! et consommateur de ressources.

+1, le remplissage de la stacktrace, ça va prendre un temps fou par rapport au continue...

[Ricky81]

Le label sert si tu veux sortir d'une imbrication de boucles et non juste de ta boucle courante.

[OButterlin]

+1, le remplissage de la stacktrace, ça va prendre un temps fou par rapport au continue...

Pour ce qui est du temps fou, ça me fait rigoler quand même...

Mais bon, si vous préférez un "goto", rien ne vous empêche de l'utiliser (que ce soit sur un continue ou un break), le but était de montrer qu'on peut faire sans...

[keub51]

...ou que l'on doit faire sans ...

[Deadpool]

Le goto c'est le mal

a++

Malgré tout, un certain Donald Knuth (de l'université de Stanford tout de même) a donné un cours dont le titre est Structured Programming With Goto Statements.

Ce monsieur est-il l'incarnation du mal?

[bulbo]

Pour ce qui est du temps fou, ça me fait rigoler quand même...

Mais bon, si vous préférez un "goto", rien ne vous empêche de l'utiliser (que ce soit sur un continue ou un break), le but était de montrer qu'on peut faire sans...

C'est déconseillé par Sun en tout cas dans une utilisation autre qu'exceptionnelle.

La procédure pour remplir la stack trace est loin d'être anodine et en terme de perfs on est très loin d'un continue sur un label.

C'est comme les gens qui prônent un seul return par méthode ou des méthodes de moins de 15 lignes, dans l'absolu c'est parfait, en pratique c'est du n'importe quoi.

Une écriture propre ou pas ne doit pas avoir d'impact sur les perfs du programme, et faire 5 méthodes de 15 lignes au lieu d'une grande...

1 - C'est plus long a écrire et la logique est plus dure a suivre car répartie sur 5 méthodes
2 - Ca oblige a des âneries genre utilisation de paramètres de méthodes (assez pénalisant quand même par rapport a une seule variable ou utilisation de champ privé qui en terme de design sont bien pire qu'une grosse méthode.
3 - 5 appels de méthodes ca restera toujours plus long qu'un seul.

Pour un seul return, sur une méthode de 5 lignes ok, sur une grand méthode, je préfère avoir des cas de sortie clairement identifiés dés le début que de me trimballer tout au long de l'algo pour savoir ce qui finalement se passe.

Voilou mon avis a 2 balles venant de mon expérience de développeur perso,

Bulbo

[OButterlin]

Bon, je l'avoue, c'est NETTEMENT plus simple avec un continue (ou break) -> label...
D'ailleurs, je ne savais même pas qu'on pouvait le faire (des années de programmation où le goto était tabou)...
Il faut bien sortir du dogme "ma religion me l'interdit"

(j'ai commencé à lire l'article de Donald Knuth mais c'est un peu pénible, on dirait que c'est une image, (un scan ?)... J'essayerai de trouver une autre référence)

[adiGuba]

Pour ce qui est du temps fou, ça me fait rigoler quand même...

Si c'est destiné à être exécuté dans une boucle assez importante cela peu se faire sentir...
Mais de toute manière les exceptions sont destiné à la gestion d'erreur et non pas pour "simuler" un goto...

Malgré tout, un certain Donald Knuth (de l'université de Stanford tout de même) a donné un cours dont le titre est Structured Programming With Goto Statements.

Ce monsieur est-il l'incarnation du mal?

Non...

J'ai quand même deux remarques :

• Ce document date de 1974...
• Le goto est toujours utiliser "implicitement" lorsqu'on utilise les structures de contrôles du langage (for, if, while, break, continue, try/catch/finally...), qui permettent une bien meilleur lisibilité.

Alors oui c'est possible de faire des programmes structuré avec des goto, mais cela n'apporte rien par rapport aux structures existantes dans le langage il n'y a aucun intérêt à utiliser directement le goto (en Java en tout cas)!

A moins que tu ne me trouves un exemple où l'utilisation du goto apporte un réel plus je resterais sur cette position

a++

[ghervouin]

Bulbo tu t'éloignes du sujet là mais puisque tu en parles :

Le fait de dire pas plus de 15 lignes par méthode ce n'est pas juste pour le fun ou pour faire chic, c'est parce que dès lors que tu atteinds 100 lignes dans 1 méthode celà veut simplement dire que tu dois revoir ta conception.

Tu ne programme plus en objet mais en ligne ! Rien de bien grave mais alors il Java n'est pas le language le plus approprié

[Deadpool]

Non...

J'ai quand même deux remarques :

• Ce document date de 1974...
• Le goto est toujours utiliser "implicitement" lorsqu'on utilise les structures de contrôles du langage (for, if, while, break, continue, try/catch/finally...), qui permettent une bien meilleur lisibilité.

Alors oui c'est possible de faire des programmes structuré avec des goto, mais cela n'apporte rien par rapport aux structures existantes dans le langage il n'y a aucun intérêt à utiliser directement le goto (en Java en tout cas)!

A moins que tu ne me trouves un exemple où l'utilisation du goto apporte un réel plus je resterais sur cette position

Non, non, c'était plus une boutade qu'autre chose, en fait j'ignorais même que c'étais si vieux.

Je suis plutôt du même avis que toi.

[bulbo]

Bulbo tu t'éloignes du sujet là mais puisque tu en parles :

Le fait de dire pas plus de 15 lignes par méthode ce n'est pas juste pour le fun ou pour faire chic, c'est parce que dès lors que tu atteinds 100 lignes dans 1 méthode celà veut simplement dire que tu dois revoir ta conception.

Tu ne programme plus en objet mais en ligne ! Rien de bien grave mais alors il Java n'est pas le language le plus approprié

C'est bien ce que je dis, tu n'as jamais eu un algo de plus de 100 lignes ? Moi j'en ai un que je serais bien en peine de factoriser et si je devais créer des méthodes pour réduire la taille du code, ce serait complètement artificiel et absolument pas une meilleure conception.

Il faut arrêter de rester braquer sur ce que vous avez appris a l'école (sauf si vous y êtes encore, le prof apprécie qu'on se souvienne de ce qu'il dit )

Il y a des algos qui sont long c'est comme ça, et un algo long n'a rien a voir avec la conception.

Mon algo de 30 km (je pense que ça doit être le plus long de ma carrière) je ne l'ai pas écrit pour me pourrir la vie (je ne sais pas combien il me fait de pages écran mais c'est sur qu'on a vu mieux niveau maintenance).

Je dois récupérer une donnée pour une position, si cette donnée n'est pas dispo pour cette position, je peux utiliser (si défini) une position proche, si enfin la position proche non plus n'arrive pas a me fournir l'info je retourne une valeur par défaut pour les x prochaines requetes ou durant un temps donné.

J'ai un objet qui gère l'état d'une position, j'ai un objet qui correspond a la position (avec la fallback position) qui vient de ma DB, j'ai une hashtable pour stocker mes états par connection ...
J'ai un objet CORBA que j'utilise pour faire les requêtes pour les positions.

Rien que la description de l'algo (abrégée en plus, je dois tenir compte des messages d'erreur, certains messages ne nécessitant pas l'appel sur la position proche) fait déjà 4 lignes.. pas sur que le "casser" sur plusieurs méthodes va relever d'une meilleure conception

Bulbo