La syntaxe de goto en Java

Version imprimable

24/09/2007, 11h35
sabrinabest

La syntaxe de goto en Java

Bonjour,

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

Merci d'avance pour votre aide.
24/09/2007, 11h38
adiGuba

Salut,

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

Le goto c'est le mal :aie:

a++
24/09/2007, 12h57
OButterlin

Citation:

Envoyé par adiGuba

Le goto c'est le mal :aie:

:king: adiGuba (Bush ???)

Pour le reste, il a raison...
24/09/2007, 14h43
deltree

revival goto

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.
24/09/2007, 15h11
Fifan31

Citation:

Envoyé par 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.

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.
24/09/2007, 15h38
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:

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

On peut faire ça sans etiquette aussi...

Code:

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:

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...;)

24/09/2007, 16h46
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" :roll: 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 ;)
10/10/2007, 20h26
Laurent.B

Perso, je dirais que sortir avec une exception c'est super cracra !! et consommateur de ressources.
10/10/2007, 21h15
denisC

Citation:

Envoyé par Laurent.B

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...
10/10/2007, 21h53
Ricky81

Le label sert si tu veux sortir d'une imbrication de boucles et non juste de ta boucle courante.
11/10/2007, 10h21
OButterlin

Citation:

Envoyé par denisC

+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...
11/10/2007, 10h37
keub51

...ou que l'on doit faire sans ...
11/10/2007, 11h03
Deadpool

Citation:

Envoyé par adiGuba

Le goto c'est le mal :aie:

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? :aie:
11/10/2007, 11h19
bulbo

Citation:

Envoyé par OButterlin

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 ;)
11/10/2007, 11h20
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" :mrgreen:

(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)
11/10/2007, 11h26
adiGuba
Citation:

Envoyé par OButterlin

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...

Citation:

Envoyé par Deadpool

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? :aie:

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 :arrow: 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++
11/10/2007, 11h45
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é ;)
11/10/2007, 11h57
Deadpool
Citation:
Envoyé par adiGuba

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 :arrow: 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. :mouarf:
11/10/2007, 12h00
bulbo

Citation:

Envoyé par 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é ;)

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 :P)

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 :roll:

Bulbo ;)
11/10/2007, 12h22
ghervouin

C'était juste histoire de chambrer un peu...

Ca fait 6 ans que je développe avec les patterns et tout le bazar et c'est vrai que dès que tu manipules des frameworks techniques, t'es bien obligé de cracher de la ligne de code à la suite...

Je suis bien d'accord avec toi en tout cas que de factoriser du code pour le plaisir n'a absolument aucun intérêt. D'ailleurs concevoir n'a rien à avoir avec factoriser du code !

Voilà mon avis à 2 balles...
11/10/2007, 12h28
OButterlin

Citation:

Envoyé par ghervouin

Voilà mon avis à 2 balles...

Et voilà l'travail ! Tu t'es fait corriger par des gens qui ne sont pas là pour rigoler ou qui ont également la tête dans le c.. (Je parle pour moi les gars, inutile de m'envoyer bouler, j'rigole :mrgreen:)

1 pièce(s) jointe(s)

Je déterre ce message – j'adore déterrer – pour exposer mon expérience récente (la dernière heure) :

Pour moi, l'absence de goto en Java, bien que venant d'intention louables, pose quand même problème dans certaines situations un peu particulières.

Pièce jointe 165692

Quand ce flux est contenu dans une seule et unique méthode, j'utilise return (attention, c'est du EBean et tout un foutoir de Json...) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public void setAdresse(JsonNode adresse) {
        if (adresse.has("id")) {
            this.adresse = Adresse.find.byId(UUID.fromString(adresse.get("id")
                    .asText()));
            if (this.adresse != null)
                return;
        }
        List<Adresse> adresseList = Adresse.search(adresse);
        if (adresseList.size() == 1) {
            this.adresse = adresseList.get(0);
            return;
        }
        this.adresse = Adresse.fromJson(adresse);
    }

Quand je ne peux pas sortir d'une méthode (la logique n'est qu'une partie d'une méthode un peu plus vaste), c'est moche, j'utilise une fausse boucle while, un label et des break :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
bloc: while (true) {
                if (contactNode.has("id")) {
                    contact = Contact.find.byId(contactNode.get("id").asInt());
                    if (contact != null)
                        break bloc;
                }
                List<Contact> contactList = Contact.search(contactNode);
                if (contactList.size() == 1) {
                    contact = contactList.get(0);
                    break bloc;
                }
                contact = Contact.fromJson(contactNode);
                break bloc;
            }

Bien sûr, il y a probablement d'autres solutions, c'est la plus claire que j'ai trouvée pour le moment. Je vois difficilement comment factoriser ce genre de truc.

Citation:

Envoyé par Pierre-Yves Le Dévéhat

Quand je ne peux pas sortir d'une méthode (la logique n'est qu'une partie d'une méthode un peu plus vaste),

Situation parfaitement illégitime et indéfendable.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
address = extractAddress(contactNode);
 
/* ... */
 
private static String extractAddress(JsonNode adresse) {
  if (adresse.has("id")) {
    String candidate = Adresse.find.byId(UUID.fromString(adresse.get("id")
      .asText()));
    if (candidate != null) {
      return candidate;
    }
  }
 
  List<Adresse> adresseList = Adresse.search(adresse);
  if (adresseList.size() == 1) {
    return adresseList.get(0);
  }
  return Adresse.fromJson(adresse);
}

Ou alors :

Code:

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
28
29
30
address = AddressExtraction.fromNode(contactNode);
 
/* ... */
 
class AddressExtraction {
 
  static String fromNode(JsonNode adresse) {
    String candidate = byId(adresse);
    if(candidate == null) {
 
      List<Adresse> adresseList = Adresse.search(adresse);
      if(adresseList.size() == 1) {
        return adresseList.get(0);
      } else {
        return Adresse.fromJson(adresse);
      }
    } else {
      return candidate;
    }
  }
 
  private static String byId(JsonNode adresse) {
    if (adresse.has("id")) {
      return Adresse.find.byId(UUID.fromString(adresse.get("id")
        .asText()));
    } else {
      return null;
    }
  }
}

Ce ne sont pas les solutions simples, claires et donc par définition bien meilleures que du goto, qui manquent.

10/01/2015, 16h48
professeur shadoko
pour les amateurs de curiosités (et sans rapport direct avec les gotos)
Code:

1 2 3 4 SI_TOUT_OK: { //codes }
petit challenge à la communauté: exhiber des exemples pertinents d'utilisation de ce truc en Java :roll:
(de mémoire je crois que ça m'est arrivé deux fois ... mais il faudrait que je me plonge dans mes archives :oops:)
15/01/2015, 13h04
Pierre-Yves Le Dévéhat

Citation:

Envoyé par thelvin

Ce ne sont pas les solutions simples, claires et donc par définition bien meilleures que du goto, qui manquent.

Effectivement, je trouvais juste que devoir créer une méthode byId était un peu de trop, mais c'est toujours plus élégant que ce que je proposais.
Sinon, juste pour info, dans mes exemples, on n'attend pas une String mais un objet Adresse. J'ai adapté, notamment en incorporant les méthodes extract et byId à la classe Adresse (évitant ainsi de devoir les reproduire dans toutes les autres classes nécessitant ce mécanisme de récupération d'Adresse). Merci, en tous cas, pour le coup de main.