Alternative à une instruction goto en Java

Ce qui est une autre fonction pour le goto mot-clé en Java?

Depuis Java ne dispose pas d'un goto.

  • Vous demandez la curiosité, et vous n'allez pas l'utiliser dans un véritable programme Java, droit?
  • son OK ... il ne peut pas, même si il veut 🙂
  • Pouvez-vous donner un exemple du type de code que vous écrivez si goto est disponible en Java? Je pense que c'est là que réside la question la plus importante.
  • Je seconde polygene, pourriez-vous s'il vous plaît mettre à jour votre question à indiquer pourquoi votre programme a besoin d'un goto?
  • suis dans la boucle while, au cours d'une itération, il y a 3 conditions sur la base des critères de condition, je veux transférer les controlto directement
  • En fait, Java a le mot-clé goto cependant il n'existe pas de situation dans laquelle vous pouvez l'utiliser. par exemple, const. Au lieu de goto, vous pouvez utiliser continuer, break, interrupteur, le retour d'un sous-méthode. Cela dépend de ce que vous essayez de faire.
  • On parle toujours de ne jamais utiliser un goto, mais je pense qu'il y a vraiment une bonne utilisation dans le monde réel de cas qui est assez bien connu et utilisé.. C'est à dire, faire assurez-vous d'exécuter du code avant un retour de fonction.. en général, sa suppression des verrous ou ce n'est pas, mais dans mon cas, j'aimerais être capable de sauter d'une pause juste avant le retour afin que je puisse faire obligatoire de nettoyage. Bien sûr, un programme salie avec des goto partout serait horrible, mais si restreint pour le corps de méthode, il ne semble pas que du mauvais, aussi longtemps que vous suivez une convention (seulement passer à la fin de fonctions, de ne jamais sauvegarder)
  • Vous êtes en bonne compagnie. Linus Torvalds a passionnément défendu goto kerneltrap.org/node/553. Sans doute le plus notable de l'omission de Projet de Pièce de monnaie.
  • Je suis face à un même problème aussi. Donc je suis en utilisant poursuivre, mais il montre l'erreur qu'une boucle lable: myLable. Ne continuer à travailler uniquement avec des boucles?
  • n'essayez pas-enfin faire le travail dans cet exemple?
  • try/finally fonctionne bien dans la plupart des cas, et je dirais que c'est suffisant. Le seul inconvénient est que vous ne pouvez pas simplement sauter à la clause finally (facilement). Peut-être que vous pouvez lancer manuellement une exception que vous êtes attraper silencieusement de le faire bien (pas sûr si cela fonctionne mais je ne vois pas pourquoi il ne serait pas).
  • au lieu de cela, vous pouvez utiliser une instruction if pour bloquer le reste de votre code. 🙂
  • Vous avez besoin d'imaginer un code qui est profondément imbriquée déjà bien.. Comment voulez-vous empêcher quelqu'un d'écrire du code dans le futur et qui est exécuté à l'extérieur que si l'instruction.. dire que vous êtes déjà 3 niveaux de profondeur dans si les déclarations quand vous arrivez à ce point où vous avez besoin pour nettoyer et sortir de la routine.
  • finally capte le chemin d'exécution pour break trop, de sorte que vous pouvez passer à la enfin avec try { do { break; } while (false) } finally { } mais bien sûr finally n'est nécessaire que si vous êtes returning ou attendre une exception ainsi que faire la break: si vous n'êtes breaking puis do{ } while(false) suffira.
  • Je ne savais pas que vous pourriez pause d'une instruction try. Nice!
  • Vous ne pouvez pas casser à partir d'une instruction try". La pause est de le "faire". Le point est, quand à la fin de l'essai est atteint -- par quelque moyen que ce soit -- enfin à exécuter. Même si vous utilisez un "retour". La définition de enfin, c'est qu'il va exécuter lorsque le contrôle des feuilles de la "essayer". N'importe comment. Donc, si vous avez le code que vous voulez passer, et ne vois pas de moyen simple de les envelopper dans une "si" comme Andres suggère, mettre le try/finally dans sa propre routine, de sorte que vous pouvez utiliser le bouton "retour".
  • Bon point, try{}finally{} est probablement une meilleure solution dans la plupart des cas de goto. FWIW, je n'ai jamais utilisé une instruction goto en c ou en toute autre langue qui la prend en charge.
  • 3 conditions: Commutateur si le 3 ne diffèrent que de la valeur (cas 1, cas 2, 3). "If / else if / else", pour des maladies plus complexes.
  • Vous pouvez utiliser des gotos correctement (si il ya un tel terme) à l'aide de ce bytecode à la modification de la bibliothèque github.com/footloosejava/JavaGoto
  • vous faites une supposition erronée. Java depuis que j'ai rememeber a toujours eu le goto mot-clé. docs.oracle.com/javase/tutorial/java/nutsandbolts/... . ( Croyez-moi, c'est une très délicate question de la certification. )

InformationsquelleAutor gmhk | 2010-03-12
  1. 81

    Vous pouvez utiliser une étiquette PAUSE déclaration:

    search:
    for (i = 0; i < arrayOfInts.length; i++) {
        for (j = 0; j < arrayOfInts[i].length; j++) {
            if (arrayOfInts[i][j] == searchfor) {
                foundIt = true;
                break search;
            }
        }
    }

    Cependant, dans bien conçus code, vous ne devriez pas avoir besoin GOTO fonctionnalité.

    • Ce ne sera pas vous faire économiser de l'rapaces!
    • Pourquoi devriez-vous pas besoin goto fonctionnalité correctement conçus code?
    • Parce que l'assemblée est la seule personne autorisée à l'utiliser. Une instruction while, une déclaration, un tout, un foreach, un appel de fonction, tous ces éléments sont les instructions GOTO utilisé de manière contrôlée et prévisible. Au niveau de l'assembleur, il sera toujours GOTOs, mais vous ne devriez pas avoir besoin de la fonctionnalité pure GOTO vous donne - son seul avantage sur les fonctions et boucle/instructions de contrôle est qu'il vous permet de sauter au milieu de tout code, n'importe où. Et que "avantage" est lui-même la définition de "code spaghetti'.
    • Voici la célèbre 1968 lettre par Edsger W. Dijkstra qui explique pourquoi il a considéré comme goto nuisibles.
    • Je suis assez convaincu qu'un code écrit, par exemple dans le cas de l'utilisation de la double boucle de lancer à une méthode, et l'utilisation de retour au lieu de casser des blocs. J'ai travaillé avec un gars, il a appris à programmer dans les années 80 et il a écrit de 1000 à 1500 lignes de méthodes en java, à l'aide de blocs, les pauses, et, ensemble, au lieu d'essayer de réparer son code nous avons simplement remplacé elle est basée sur la Spécification des exigences. Je crois que "goto" comme de la programmation appartient à avant les années 90 et devrait y rester. Vraiment.
    • Une boucle while est une instruction goto. Aussi, je ne peux penser à quelques situations où un goto serait plus élégant, mais dans toutes ces situations, vous pouvez utiliser une instruction while à la place. C'est peut-être de l'assemblée que j'ai écrit, mais dans ces cas, l'instruction goto semble toujours être la "bonne" réponse, même s'il est dangereux de réponse. La boucle while semble toujours post-facto.
    • Merci de ne pas dire "une boucle while est une instruction goto." Oui, le compilateur met en œuvre à l'aide d'une branche. MAIS CE N'EST PAS LE POINT. Lors de la rencontre d'un goto, vous devez vous demander: POURQUOI est-ce ramification? N'direction générale de l'informatique d'une manière sûre? Cela pourrait-il être la cause de certains bug? Lors de la rencontre d'une routine avec plusieurs gotos, ma réaction basée sur l'expérience de débogage est "cela va être mauvais". Moderne constructions de flux de contrôle (alors que, etc) vous dire exactement ce qui se passe. Facile à comprendre, difficile à des abus. Parfois, nettoyer la solution est de factoriser une méthode, remplacer les gotos avec des rendements.
    • Il n'existe actuellement pas d'autre moyen de mettre en œuvre une telle itération. Il est préférable de comprendre un tout énoncé comme un sous-ensemble des instructions GOTO, qui permet de comprendre ce qui se passe sous le capot.
    • ahh, en relisant TOUS vos commentaires, je vais maintenant lire différemment le point de votre relevé "Une boucle while est une instruction goto". J'ai d'abord lu comme cavalier, comme il n'a pas vraiment d'importance si on a utilisé "bien que" ou "goto", car le résultat final est le même. (n'a pas d'importance à l'ordinateur, mais les questions de la compréhension humaine, et l'écriture de code robuste-c'est ce qui m'a dérangé) Maintenant, je l'ai lu comme une réponse à zode64 du "Pourquoi pas besoin goto ...". Vous êtes en expliquant que le "goto" déclaration n'est pas nécessaire, parce que ces autres états, dont chacun est un sous-ensemble de "goto", ainsi que de couvrir les besoins.
    • Contexte pour "rapaces", xkcd #292.
    • Mojang réellement utilise cette abandonnées chose dans Minecraft source... =/
    • Je n'ai toujours pas vu d'un bon exemple de la façon de "concevoir" le code dans une situation où vous avez une série de tâches et si l'un d'eux échoue, par exemple, vous donnez le même message d'erreur. Bien sûr, vous pourriez mettre le code pour afficher l'erreur dans une fonction et de l'appeler et puis le retour, mais ce n'est pas "bien conçu" dans mon livre. Bien sûr, vous pourriez avoir un booelan didThisErrorHappen et si oui, afficher l'erreur et le retour, mais ça ne semble pas "bien conçu" pour moi, vraiment. Je préfère suffit d'utiliser goto. Mais les puristes ne semble pas aimer ça, même si utilisé correctement, il est juste une autre façon de structure.

    InformationsquelleAutor Padmarag
  2. 41

    Il n'y a pas d'équivalent direct à la goto concept en Java. Il y a quelques constructions qui vous permettent de faire certains des choses que vous pouvez faire avec un classique goto.

    • La break et continue états vous permettent de sauter d'un bloc dans une boucle ou d'une instruction switch.
    • Un rapport marqué et break <label> vous permettent de sauter hors de l'arbitraire d'un composé déclaration à n'importe quel niveau dans une méthode donnée (ou d'initialiseur de bloc).
    • Si vous identifiez une boucle de déclaration, vous pouvez continue <label> pour continuer avec la prochaine itération d'une boucle externe à partir d'une boucle interne.
    • Lancer et attraper les exceptions permet d' (efficace) de sauter de nombreux niveaux d'un appel de méthode. (Toutefois, des exceptions sont relativement coûteux et sont considérés comme d'être une mauvaise façon de le faire "ordinaire" contrôle de flux1.)
    • Et bien sûr, il y a return.

    Aucun de ces Java constructions de vous permettre de direction vers l'arrière ou vers un point dans le code au même niveau d'imbrication que l'instruction en cours. Ils ont tous sauter un ou plus de nidification (champ d'application) les niveaux et ils ont tous (à l'exception de continue) sauter vers le bas. Cette restriction permet d'éviter le goto "code spaghetti" syndrome inhérente dans le vieux BASIC, FORTRAN et COBOL2.

    1 - la partie La plus coûteuse d'exceptions est la création effective de l'objet de l'exception et de ses stacktrace. Si vous avez vraiment, vraiment besoin d'utiliser la gestion des exceptions pour "normal" contrôle de flux, vous pouvez soit préallouer /réutilisation de l'objet de l'exception, ou de créer une classe d'exception personnalisée qui remplace la fillInStackTrace() méthode. L'inconvénient est que l'exception du printStackTrace() méthodes ne vais pas vous donner de l'information utile ... si vous avez besoin de les appeler.

    2 - Le code spaghetti syndrome a donné naissance à la la programmation structurée approche, où vous limité dans votre utilisation de la langue disponible constructions. Il pourrait être appliqué à De BASE, Fortran et COBOL, mais il nécessitait des soins et de la discipline. Se débarrasser de goto entièrement était un pragmatique meilleure solution. Si vous le gardez dans une langue, il y a toujours un clown qui va en abuser.

    • Les boucles comme while(...){} et for(...){} vous permettent de répéter des blocs de code, sans explicitement de sauter à un emplacement arbitraire. Aussi, les appels de méthode myMethod() vous permettent d'exécuter du code à trouver ailleurs et revenir au bloc en cours lorsque vous avez terminé. Tous ces éléments peuvent être utilisés pour remplacer des fonctionnalités de goto tout en empêchant la commune de problème de la non-retour qui goto permet.
    • c'est vrai, mais la plupart des langues GOTO également de resserrer les analogues de Java constructions en boucle.
    • classique FORTRAN a "pour" et les boucles classiques COBOL a aussi des boucles (si je ne me rappelle pas les détails). Seulement classique de BASE n'a pas explicite les boucles ...
    InformationsquelleAutor Stephen C
  3. 29

    Juste pour le fun, ici est un GOTO mise en œuvre en Java.

    Exemple:

       1 public class GotoDemo {
   2     public static void main(String[] args) {
   3         int i = 3;
   4         System.out.println(i);
   5         i = i - 1;
   6         if (i >= 0) {
   7             GotoFactory.getSharedInstance().getGoto().go(4);
   8         }
   9         
  10         try {
  11             System.out.print("Hell");
  12             if (Math.random() > 0) throw new Exception();            
  13             System.out.println("World!");
  14         } catch (Exception e) {
  15             System.out.print("o ");
  16             GotoFactory.getSharedInstance().getGoto().go(13);
  17         }
  18     }
  19 }

    L'exécutant:

    $ java -cp bin:asm-3.1.jar GotoClassLoader GotoDemo           
   3
   2
   1
   0
   Hello World!

    Ai-je besoin d'ajouter "ne l'utilisez pas!"?

    • J'ai l'habitude de l'utiliser, son extra
    • Bug: Math.random() peut retourner 0. Il convient de >=
    • Oui bien. Tout ce qui ne peut être mis en œuvre par le bytecode hackery n'est pas vraiment de Java ...
    • Est-il quelque chose de semblable qui prend en charge les étiquettes au lieu de numéros de ligne ?
    • Le lien pour une mise en œuvre est cassé.
    InformationsquelleAutor
  4. 17

    Alors que certains commentateurs et downvoters soutiennent que ce n'est pas goto, à la génération de bytecode de la ci-dessous Java états suggère vraiment que ces déclarations vraiment faire exprès goto sémantique.

    Plus précisément, le do {...} while(true); boucle dans le deuxième exemple est optimisé par les compilateurs Java afin de ne pas évaluer la condition de la boucle.

    De saut en avant

    label: {
  //do stuff
  if (check) break label;
  //do more stuff
}

    En bytecode:

    2  iload_1 [check]
3  ifeq 6          //Jumping forward
6  ..

    Saut en arrière

    label: do {
  //do stuff
  if (check) continue label;
  //do more stuff
  break label;
} while(true);

    En bytecode:

     2  iload_1 [check]
 3  ifeq 9
 6  goto 2          //Jumping backward
 9  ..
    • Comment le faire/tout en saut en arrière? Il reste juste sauts du bloc. Contre-Exemple: label: do {System.out.println("Backward"); label continuer;} while(false); je pense que dans ton exemple le while(true) est ce qui est responsable pour le saut en arrière.
    • label est le saut vers l'arrière
    • Je ne suis toujours pas convaincu. L'instruction continue ignore l'itération courante d'un for, while ou do-while. Continuer saute à la fin de la boucle du corps, qui est ensuite évalué pour l'expression booléenne qui contrôle la boucle. Le tout est qu'est-ce que sauter vers l'arrière de ne pas la continuer. Voir docs.oracle.com/javase/tutorial/java/nutsandbolts/branch.html
    • Techniquement, vous avez raison. À partir d'un point de vue logique, si // do stuff et // do more stuff sont les déclarations d'intérêt, continue label "a l'effet" de sauter vers l'arrière (en raison de la while(true) déclaration bien sûr). Je ne savais pas que c'était une question précise, mais...
    • J'ai mis à jour la réponse. Le while(true) est traduite par le compilateur dans un goto bytecode de l'opération. Comme true est une constante littérale, le compilateur peut faire de l'optimisation et de ne pas avoir à évaluer quoi que ce soit. Donc, mon exemple est vraiment un goto, sauter vers l'arrière...
    • En examinant les octets de codes (natif ou instructions) pour déterminer si vous branche vers l'avant ou vers l'arrière manque le point. Il est bien connu que les "goto" primitives existe à ce niveau. La direction d'une instruction de saut est déterminé par le compilateur a choisi d'organiser les blocs de code, pas par le langage de programmation au niveau de la sémantique.
    • De même, le fait que, dans certains cas, vous pouvez écrire du code qui est directement équivalent à un code que vous pouvez écrire à l'aide de goto états est également à côté de l'essentiel. Le problème avec goto et pourquoi il est "considéré comme nuisible" est la façon dont la sémantique est exprimés ... et l'impact qu'il a sur code source lisibilité. (Surtout quand goto est abusé.)
    • C'est en effet l'équivalent le plus proche. La seule différence est qu'il crée un nouveau champ d'application pour le do while, mais alors nous pourrions mettre déclarations juste à l'extérieur il.
    • Wow, je viens d'apprendre quelque chose. coupure sans boucle. Qui aurait su! Cela peut effectivement être utile.
    • Ouais, c'est un sujet controversé - pas tout le monde vous aimera pour l'utilisation de cette fonctionnalité, mais je trouve qu'il est utile (très rarement) ainsi. Voici un blog que j'ai écrit à ce sujet, récemment

    InformationsquelleAutor Lukas Eder
  5. 5

    Si vous voulez vraiment quelque chose, comme les instructions goto, vous pouvez toujours essayer de briser nommée blocs.

    Vous devez être dans le champ d'application de la bloquer à la rupture pour l'étiquette:

    namedBlock: {
  if (j==2) {
    //this will take you to the label above
    break namedBlock;
  }
}

    Je ne vais pas la leçon sur pourquoi vous devriez éviter de goto - je suis en supposant que vous connaissez déjà la réponse à cette question.

    • J'ai essayé de mise en œuvre de ce dans mon DONC, la question lien ici. Il ne fait pas de vous prendre pour le "étiquette ci-dessus," peut-être que j'ai mal interprété l'auteur des faits, mais pour plus de clarté, je vais ajouter qu'il vous faut pour la fin de l'extérieur du bloc (le "marqué" bloc), ce qui est en dessous de l'endroit où vous êtes en rupture. Par conséquent, vous ne peut pas "casser" la hausse. Au moins, c'est ma compréhension.
    InformationsquelleAutor Amir Afghani
  6. 4
    public class TestLabel {

    enum Label{LABEL1, LABEL2, LABEL3, LABEL4}

    /**
     * @param args
     */
    public static void main(String[] args) {

        Label label = Label.LABEL1;

        while(true) {
            switch(label){
                case LABEL1:
                    print(label);

                case LABEL2:
                    print(label);
                    label = Label.LABEL4;
                    continue;

                case LABEL3:
                    print(label);
                    label = Label.LABEL1;
                    break;

                case LABEL4:
                    print(label);
                    label = Label.LABEL3;
                    continue;
            }
            break;
        }
    }

    public final static void print(Label label){
        System.out.println(label);
    }
    • Il en résultera une StackOverFlowException est vous fonctionner assez longtemps, donc mon besoin de goto.
    • Comment est-ce que conduire à un débordement de la pile? Il n'y a pas de récursivité dans cet algorithme...
    • Cela ressemble beaucoup à l'original de la preuve que tout programme peut être écrit sans l'aide de "goto" - en la transformant en une boucle while avec une "étiquette" à la variable qui est dix fois pire que ce que goto.
    InformationsquelleAutor code lover
  7. 3

    StephenC écrit:

    Il y a deux concepts qui vous permettent de faire certaines des choses que vous
    peut faire avec un classique goto.

    Un de plus...

    Matt Wolfe écrit:

    On parle toujours de ne jamais utiliser un goto, mais je pense qu'il y a un
    vraiment bonne utilisation dans le monde réel de cas qui est assez bien connu et utilisé..
    C'est sûr que pour exécuter du code avant un retour à partir d'un
    fonction.. en général, sa suppression des verrous ou ce n'est pas, mais dans mon cas, j'avais
    l'amour pour être en mesure de sauter d'une pause juste avant le retour afin que je puisse faire
    obligatoire de nettoyage.

    try {
    //do stuff
    return result;  //or break, etc.
}
finally {
    //clean up before actually returning, even though the order looks wrong.
}

    http://docs.oracle.com/javase/tutorial/essential/exceptions/finally.html

    Le bloc finally est toujours exécuté lorsque le bloc try sorties. Cette
    s'assure que le bloc finally est exécuté même si inattendu
    exception se produit. Mais finalement, est utile pour plus que juste l'exception
    manutention — il permet au programmeur pour éviter d'avoir un code de nettoyage
    accidentellement court-circuité par un retour, de poursuivre ou de pause. Mettre de nettoyage
    code dans un bloc finally est toujours une bonne pratique, même lorsqu'il n'
    des exceptions sont prévues.

    La stupide question d'entrevue associés avec enfin est: Si vous revenez d'un try{} bloc, mais de retour dans votre finally{} aussi, dont la valeur est de retour?

    • Je suis en désaccord que c'est une bête question de l'entrevue. Une expérience programmeur Java doit savoir ce qui se passe, si ce n'est pour comprendre pourquoi mettre un return dans un finally bloc est une mauvaise idée. (Et même si la connaissance n'est pas strictement nécessaire, je serais inquiet par un programmeur qui n'a pas eu la curiosité de le découvrir ...)
    InformationsquelleAutor android.weasel
  8. 1

    La méthode la plus simple est:

    int label = 0;
loop:while(true) {
    switch(state) {
        case 0:
            //Some code
            state = 5;
            break;

        case 2:
            //Some code
            state = 4;
            break;
        ...
        default:
            break loop;
    }
}
    InformationsquelleAutor ratchet freak
  9. 0

    D'essayer le code ci-dessous. Il fonctionne pour moi.

    for (int iTaksa = 1; iTaksa <=8; iTaksa++) { //'Count 8 Loop is  8 Taksa

    strTaksaStringStar[iCountTaksa] = strTaksaStringCount[iTaksa];

    LabelEndTaksa_Exit : {
        if (iCountTaksa == 1) { //If count is 6 then next it's 2
            iCountTaksa = 2;
            break  LabelEndTaksa_Exit;
        }

        if (iCountTaksa == 2) { //If count is 2 then next it's 3
            iCountTaksa = 3;
            break  LabelEndTaksa_Exit;
        }

        if (iCountTaksa == 3) { //If count is 3 then next it's 4
            iCountTaksa = 4;
            break  LabelEndTaksa_Exit;
        }

        if (iCountTaksa == 4) { //If count is 4 then next it's 7
            iCountTaksa = 7;
            break  LabelEndTaksa_Exit;
        }

        if (iCountTaksa == 7) { //If count is 7 then next it's 5
            iCountTaksa = 5;
            break  LabelEndTaksa_Exit;
        }

        if (iCountTaksa == 5) { //If count is 5 then next it's 8
            iCountTaksa = 8;
            break  LabelEndTaksa_Exit;
        }

        if (iCountTaksa == 8) { //If count is 8 then next it's 6
            iCountTaksa = 6;
            break  LabelEndTaksa_Exit;
        }

        if (iCountTaksa == 6) { //If count is 6 then loop 1  as 1 2 3 4 7 5 8 6  --> 1
            iCountTaksa = 1;
            break  LabelEndTaksa_Exit;
        }
    }   //LabelEndTaksa_Exit : {

} //"for (int iTaksa = 1; iTaksa <=8; iTaksa++) {"
    InformationsquelleAutor mahasam
  10. -1

    Utiliser une étiquette de briser comme une alternative à goto.

    • Cette réponse est, et a toujours été redondant
    InformationsquelleAutor apoorva
  11. -1

    Java n'a pas goto, car elle rend le code non structurées et pas clair à lire. Toutefois, vous pouvez utiliser break et continue comme civilisé forme de goto sans ses problèmes.

    De saut en avant à l'aide de pause - 

    ahead: {
    System.out.println("Before break");
    break ahead;
    System.out.println("After Break"); //This won't execute
}
//After a line break ahead, the code flow starts from here, after the ahead block
System.out.println("After ahead");

    Sortie:

    Before Break
After ahead

    Saut vers l'arrière à l'aide de poursuivre

    before: {
    System.out.println("Continue");
    continue before;
}

    Cela entraînera une boucle infinie, comme à chaque fois la ligne continue before est exécutée, le flux de code va commencer à nouveau à partir de before.

    • Votre exemple sur le saut vers l'arrière à l'aide de poursuivre est faux. Vous ne pouvez pas utiliser "continuer" en dehors du corps d'une boucle, il cause une erreur de compilation. L'intérieur d'une boucle, cependant, continuer tout simplement sauts la boucle conditionnelle. Donc, quelque chose comme while(true){continue;} serait une boucle infinie, mais c'est while(true){} pour cette question.
    InformationsquelleAutor Confuse