continue bei labels

[hdi]

Hey,
per Zufall bin ich grad über Labels in Java gestolpert. Wusste nach über 2 Jahren Java
programmieren nicht, dass es diese Syntax überhaupt gibt

[HIGHLIGHT="Java"]YEAHCOOL: {...}[/HIGHLIGHT]

seeeehr nice, ich hab mir n Bsp geschrieben was ich mir schon immer herbeigesehnt hab,
aber dachte dass sowas nicht möglich ist:

[HIGHLIGHT="Java"]// say you want to abort the whole process at i == 5 and j == 5:
BREAKLABEL: {
for (int i = 0; i < 10; i++) {
for (int j = 0; j < 10; j++) {
System.out.println("i = " + i + ", j = " + j);
if (i == 5 && j == 5) {
break BREAKLABEL;
}
/*
* without the label, we would need a boolean 'stop' which
* is set to true before breaking the inner loop, and then:
* if(stop){ break; } here. Because of the label, we can break the
* whole process.
*/
}
}
}[/HIGHLIGHT]

Das is sowas von geil =) Ich hab es bisher eben immer mit diesem Hilfs-Boolean gemacht,
und bei 4 verschachtelten Schleifen nervt das...

Aber nun mal zur Frage
Das ganze gibt's auch mit continue, aber funzt bei mir nicht. Ich kann kein

[HIGHLIGHT="Java"]continue SOMELABEL;[/HIGHLIGHT]

machen, er sagt mir immer "continue cannot be used outside of a loop", obwohl
es in nem Loop steht.
Irgendwie check ich das nicht, kann mir bitte einer ein kompilierbares Bsp mit
continue und einem Label geben? (Ohne Label geht es)

 

[SlaterB]

continue Label java - Google-Suche
->
Branching Statements (The Java™ Tutorials > Learning the Java Language > Language Basics)
http://java.sun.com/docs/books/tutorial/java/nutsandbolts/examples/ContinueWithLabelDemo.java

(edit: diese automatischen Link-Titel sind schon was feines )

 

[hdi]

Ist nicht so, dass ich nicht selbst probiert hätte. Hab auch ein Bsp hergenommen.
Seltsamerweise (so seh ich das jetzt grad) funzt der Code im Link.

Aber verrat mir mal warum das hier nicht geht:

[HIGHLIGHT="Java"] test: {
for (int x = 0; x < 10; x++) {
while (true) {
continue test;
}
}
}[/HIGHLIGHT]

 

[SlaterB]

liegt vielleicht an der Klammer zwischen Label und Schleife

 

[hdi]

Hast Recht! Komisch, beim breaken gibt das keine Probleme, wie mein obiger Code zeigt.

 

[Wildcard]

Gewöhne dir diesen Mist gar nicht erst an.

 

[hdi]

Also mein obiges Bsp halte ich grad überhaupt gar nicht für Mist. Der Vorteil steht ja im Kommentar,
und wie gesagt: Ich hab mir das schon immer gewünscht gehabt.

Aber ich lerne ja gerne dazu, ist auch nicht so dass ich mich nicht schon gefragt habe, wieso
ich das erst nach über 2 Jahren erfahre...

Also was ist der Mist dran? Since 1.7? ^^

 

[Wildcard]

Weil es goto ist und goto des Teufels ist. In Java ging man anfangs den Kompromis ein es im engen Scope von Schleifen zu erlauben, aber man sollte gar nicht in die Verlegenheit kommen so komplexe Schleifen zu produzieren das Sprunglabels nötig werden.
Frag dich mal: Warum hast du in deinen 2 Jahren wohl noch nichts über Sprunglabels gelesen oder bist noch nicht darüber gestolpert?
Es ist ein kleines schmutziges Geheimnis der Sprache das am besten in Vergessenheit gerät.

 

[hdi]

Frag dich mal: Warum hast du in deinen 2 Jahren wohl noch nichts über Sprunglabels gelesen oder bist noch nicht darüber gestolpert?

ist auch nicht so dass ich mich nicht schon gefragt habe, wieso
ich das erst nach über 2 Jahren erfahre...

[...]so komplexe Schleifen zu produzieren das Sprunglabels nötig werden.

[HIGHLIGHT="Java"]if ( isSomething == true )
vs:
if ( isSomething ) // nicht nötig

if ( x < 10 ){...}
if ( x >= 10){...}
vs:
if ( x < 10 ){...}
else{...} // nicht nötig[/HIGHLIGHT]

...also was heisst bei dir "nötig"?
Ich sehe einfach keinen Grund, warum ich die Info, ob eine innere Schleife gebreaked
oder ordnungsgemäss durchgelaufen wurde, über eine Variable nach außen tragen muss,
wenn ich gleich alles breaken kann.

Bei 3 verschachtelten Schleifen sind das schon mal (schön formatiert) 9 extra-Zeilen,
das pumpt das ganze Konstrukt unnötig auf.
Und ich hatte sowas schon oft genug in der Praxis, zuletzt bei einer rekursiven Methode
mit 2 verschachtelten Schleifen.

Ein

[HIGHLIGHT="Java"]boolean shouldSkip = false;
for(...){
for(...){
if(...){
shouldSkip = true;
break;
}
}
if(shouldSkip){
break;
}
}[/HIGHLIGHT]

ist doch einfach hässlicher als obige Variante.

Hm... ich glaube halt nicht an Gott und Teufel, ich würd schon gern nen richtigen Grund
hören, warum man das vermeiden sollte. Bei Auto-Boxing/Generics ist es Buganfälligkeit zB.

Aber ich finde die Variante mit dem label break nicht buganfällig oder sonst was, ich finde
sie macht es im Gegensatz sogar viel besser lesbar, es ist doch sofort klar was passiert.

Oder ist dieses interne goto im Kern von Java buggy?

 

[Wildcard]

Weder Auto-Boxing, noch Generics, noch Sprunglabel sind Buggy.
Ein goto kann tatsächlich zu kürzerem Code führen und in einigen wenigen Fällen vielleicht sogar zu übersichtlicherem, aber ein goto bleibt ein goto und bedeutet nichts anderes als Spaghetticode.
Falls dich interessiert wie die Sache anfing, das geht auf diesen Brief zurück:
http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD215.PDF
Lass deine Schleife ein wenig länger werden, das sie nicht mehr auf einen Bildschirm passt, lass einen zweiten Programmierer eine Änderung einpflegen. Plötzlich wirst du feststellen, das er einen Bug eingebaut hat, weil er darauf vertraut hat, das ein bestimmter Code Teil zu einem bestimmten Zeitpunkt ausgeführt wurde, aber dein goto Statement (das er gar nicht bemerkt hatte), hat ihm einen Strich durch die Rechnung gemacht.

 

[hdi]

Hm, naja

Spontan würde ich zu deinem Bsp sagen, wenn du schon von einem Programmierer ausgehst,
der in verschachtelte Schleifen etwas codet ohne genau zu verstehen was da passiert, dann
mach ich für diesen Kerl halt ein Comment hin und gut is:

[HIGHLIGHT="Java"]LABEL: {
for(..){
for(..){
for(..){
if(..){
break LABEL;
}
}
} // within a break label
} // whtin a break label
}[/HIGHLIGHT]

Aber sry... man sieht sich die äußerste Schleife an wenn man in so einem Konstrukt
rumschreibt, und man sieht das Label sofort, und genauso wie man bei normalen
breaks diese auch erst ausfindig machen muss, ist das bei break LABEL nix anderes.
Man muss nur sehen was das Label alles enthält, und dazu reicht ein Klick auf
die öffnende Klammer.Auch genauso, wie bei normalen breaks, und nicht aufwändiger
oder komplizierter oder verwirrender oder whatever.
(Wobei ich jetzt nich weiss ob du auch von normalen breaks redest, das ist ja auch goto.)

Aber ich will keine diskussion anfangen. Bei komplexeren Schleifen werd ich's wohl lassen,
ich denke konkret mein obiges Bsp wird mir aber keiner Übel nehmen

 

[0x7F800000]

bei komplizierten verschachtelten schleifen sollte man nachachauen, ob man nicht wenigstens eine Stufe in eine separate Hilfsmethode auslagern kann.
Bei billigen oder kurzen schleifen finde ich alle möglichen breaks aber unproblematisch, weiß auch nicht, warum die profis dauernd so einen aufstand machen. Wahrscheinlich haben die einfach schon längst vergessen, dass es simple probleme gibt

 

[Empire Phoenix]

Der Grund warum man mit Java programmiert ist doch gerade eine sichere und relativ saubere Sprache.

Theoretisch ist auch gegen Pointer in C++ nichts zu sagen... Aber jeder wird schonmal einem Programm mit einem darauf zurückzuführenden Bug begegnet sein. Weil auch bei allen Kommentaren und sonstwelchen Hilfen, Fehler treten immer mal auf, und desshalb sollte man ihnen gar nicht erst die Chance geben.

Allerdigs ist dies natürlich nur meine Meinung, letztendlich muss jeder Wissen was er selber Macht, und auch dafür geradestehen können.

 

[HarpGoil]

@hdi

[HIGHLIGHT="Java"]
HELLO_FOR:for(int i = -1;++i < 10{
HELLO_WHILE:while(true){
if(DO_CONTINUE) continue HELLO_WHILE;
break HELLO_FOR; //schleifen verlassen
}
}

//für continue LABEL muss das LABEL zu einer schleife gehören
HELLO_UNSINN:{
while(true) continue HELLO_UNSINN; //HELLO_UNSINN ist kein label einer schleife
break HELLO_UNSINN;
}[/HIGHLIGHT]

 

[ARadauer]

Ich denke des es keine tragik ist, wenn man mal ein Sprunglabel verwendet, ich würde jetzt keinen anmotzen wenn er es bei einfachen schleifen tut.
Ich finde aber auch das man versuchen sollte sie zu vermeiden, ganze ehrlich ich denke das ich sicher schon mein 75000 Lines of Code beisammen habe, aber ich hab noch nie Sprunglabels benutzt.

 

[Ark]

Ich weiß gar nicht, was ihr (die, die sich gleich angesprochen fühlen) gegen Labels habt. Im Vergleich zur Anzahl an Schleifen, die ich programmiere, sind es schon mal wenige, die überhaupt mit Labels markiert werden. Von denen wiederum werden die meisten Labels von mir nur benutzt, um mittels break alle Schleifen auf einmal zu verlassen. Ein break "zwischendurch" kommt extrem selten vor, falls überhaupt, und ähnlich selten verwende ich continue mit Label. Na ja, und außerdem kommt man immer am Label vorbei, bevor es eingesetzt wird, und insofern kann man sich schon darauf vorbereiten, dass diese Schleifenmarke (Sprungmarke wäre wohl übertrieben) auch benutzt wird. Außerdem bekommt ein Label von mir eine ganze Zeile nur für sich reserviert.

Ich finde, dass Labels an sich (zumindest von mir) schon selten benutzt werden, und wenn, dann zur Codevereinfachung (anstatt mit booleans zu arbeiten etc.). Aber jedem das seine.

@Wildcard: Zeig mir doch bitte ein Beispiel in Java, wo Labels tatsächlich den Code unübersichtlicher oder schwerer lesbar machen.

Ark

 

[Wildcard]

@Wildcard: Zeig mir doch bitte ein Beispiel in Java, wo Labels tatsächlich den Code unübersichtlicher oder schwerer lesbar machen.

Es steht doch wohl ausser Frage dass du bei ohnehin schon komplexen verschachtelten Schleifenkonstrukten die Komplexität weiter steigeren kannst indem du den geordneten Kontrollfluss verlässt um von nun an wild durch die Gegend zu hüpfen.
Ich sage nicht das es die Sache in absolut jedem Fall verkompliziert, aber das ein Beispiel existiert kann ja wohl schlecht abgestritten werden.
Also werde ich mich mit Sicherheit nicht hinsetzen und irgendein komplexes Konstrukt bauen, das ich persönlich für Mist halte nur um das offensichtliche zu belegen.
Die Frage ob man Sprunglabels in einem Fall in dem sie tatsächlich helfen können verwendet, oder kathegorisch ablehnt, ist auch mit dem Broken Windows Syndrom verknüpft.
Lässt man es einmal geschehen, kommt gleich der nächste und der nächste und der nächste.

 

[hdi]

Ich denke, was du sagen willst, ist eher, dass man absolut krass verschachtelte
Schleifen vermeiden soll, und nicht Labels. Kann das sein?
Denn ob break/continue oder break X/continue X macht kaum noch einen Unterschied.

Mit normalen breaks und 14-fachen Schleifen hau ich dir genauso nen Knoten ins Hirn,
auch ohne Labels

 

[0x7F800000]

Es steht doch wohl ausser Frage dass du bei ohnehin schon komplexen verschachtelten Schleifenkonstrukten die Komplexität weiter steigeren kannst indem du den geordneten Kontrollfluss verlässt um von nun an wild durch die Gegend zu hüpfen.

Nunja... Das ist doch dasselbe wie immer: wenn man in java programmiert, sollte der code nicht nach brainfuck aussehen. Labels machen aus simplen code nicht unbedingt gleich Brainfuck. Andererseits, wenn man Spaghetticode produzieren will, erreicht man dieses unheilige Ziel auch ohne Labels...

Sagen wir einfach so: Labels und Spaghetticode stehen in nicht allzu schwacher Korrelation. Implikationen wie "Labels=>Spaghetticode" bzw "Spaghetticode=>Labels" sind dennoch übertrieben. Können wir uns auf diese Formulierung bitte einigen?

Diese ganzen wortreichen Glaubenskriege, omg... Gibt es dafür im Netzjargon eigentlich irgendeinen Fachbegriff?

 

[hdi]

Nein bitte nicht, das wäre ja eine Diskussion auf einer Seite. Das ist nix wahres

edit: Ja das Fachwort nennt sich "Langeweile"

 

[0x7F800000]

Nein bitte nicht, das wäre ja eine Diskussion auf einer Seite. Das ist nix wahres

Ich bin eben ein Spielverderber und ein abscheulicher Diversant, beschäftige mich in der letzter Zeit intensiv mit Sabotage von Diskussionen.

SHIT!
2. Seite => Mission fehlgeschlagen^^

 

[hdi]

Kommt gut im Lebenslauf. Und wenn dir der Chef was anderes sagen will, dann diskutier ihm
einfach das Gegenteil herbei

 

[maki]

Wer labels im Java Quellcode verbaut sollte besser Bäcker werden
nix für ungut

Mal ernsthaft, labels sind bäh, hat nix mit sauberem Code zu tun, wie bereits erwähnt so etwas gar nicht erst angewöhnen.
4 geschachtelte schleifen?
Naja, in diesem Falle ändert das Labels wohl nix mehr an der Code Qualität

 

[Ebenius]

Ich hab's vorhin schon schreiben wollen und dann gelassen.

Hiermit bekenne ich mich dazu, in den > 2.000 Klassen die ich in den letzten 4 Jahren geschrieben habe (weiter kann ich nicht gucken, hab die Firma gewechselt) 12 continue-mit-Label- und 5 break-mit-Label-Konstrukte verwendet zu haben. Ich überlege jedes mal, ob ich mit einem anderen Weg besser lesbaren Code erzeugen kann und mache das auch, wenn dem so ist. Was übrig bleibt erfüllt meinen Anspruch, den mir bestmöglichen Code geschrieben zu haben. "Bestmöglich" im Sinne von "am besten lesbar", "prägnant" und "funktional".

Also, maki, schmier Dir die ganzen "diese Konstrukte sind böse"-Gesetze in die Haare; das alles sind Faustregeln die oft aber nicht immer gelten.

PS:

Wer labels im Java Quellcode verbaut sollte besser Bäcker werden

Meine Mutter sagte früher: Wer Flecke (aka Kuddeln, Kaldaunen) isst, der isst auch kleine Kinder. Ich habe inzwischen viele Schwaben kennen gelernt, denen ich das eine aber nicht das andere zutraue. Wierum ich das wohl gemeint habe???

Ebenius

 

[maki]

Also, maki, schmier Dir die ganzen "diese Konstrukte sind böse"-Gesetze in die Haare; das alles sind Faustregeln die oft aber nicht immer gelten.

Ich schmier mir gerne so einiges in die Haare, aber weil du mal ein paar mal verwendet hast heisst das nicht das sie ok sind.

Habe noch nie ein Label verwendet in Java, genausowenig wie in C/C++.
Es geht auch ohne.
Habe natürlich den einen oder anderen Bockmist gebaut.. würde aber nicht empfehlen diesen zu wiederholen oder gar als "normal" zu deklarieren.

Das man hin und wieder ein paar Grundregel bricht ist nicht ungewöhnlich, aber sie deswegen als ungültig zu erklären ist nicht richtig.

 

[0x7F800000]

Wer labels im Java Quellcode verbaut sollte besser Bäcker werden

ich bleibe stets bei dem selben beispiel, den ich hier vor einem jahr schon angeschrieben habe:

Gegeben ist eine Quadratische Matrix mit nxm einträgen, die etwa so aussehen kann:

00000000000000000
00001001100100110
00010011001010001
00000010100110010
00001010100110101

finde irgendeine Spalte, in der eine 1 vorkommt.
Wie willst du das ohne "break outerloop;" lösen?
Klar, man kann das einfach in eine separate methode auslagern, und dort wo das break stehen würde, ein return einfügen, der die spaltennummer ausgibt.

Dann hat man für einen einzigen billigen 3-Zeiligen zwischenschritt, der in absolut keiner anderen Rechnung jemals wieder vorkommt eine (ohne kontext beinahe sinnfreie) methode geschrieben.

Das schreiben dieser methode an sich tut ja auch keinem weh. ABER: eher benutze ich einen label, als einen "guten" Namen für eine derart unbenennbare Methode auszudenken. "getFirstRowContainingNonNullEntry" oder was... finde ich nicht so schön

Falls dich interessiert ob und wozu man solchen Mist braucht: man braucht das beispielsweise an einer Stelle im Berlekamp-Algorithmus, der ist ganz lustig^^ Auch wenn das in einer J2EE Anwendung sehr schwer zu verbraten ist

 

[Ebenius]

Ich habe gerade festgestellt, dass die Weinflasche wider Erwarten schon leer ist. Das erklärt meine unschöne Wortwahl oben. Entschuldigung.

Als "ungültig" erkläre ich die Regel nicht (schrieb ich auch nicht). Man sollte aber darauf achten, sie nicht wie ein Gesetz zu postulieren. Die Stellen die ich mir eben in meinem Code angesehen habe sind in Ordnung und ich würde sie an dieser Stelle wieder mit Labels lösen. Natürlich kann man jedes Label-Konstrukt in Java umgehen. Da stellt sich kein Problem. Aber nur zum Selbstzweck würde ich Labels nicht pauschal verbieten.

BTW: Hab mich allerdings verzählt. Sind nur 8 continue-Label und drei break-Label-Konstrukte. Das eine Projekt liegt derzeit nochmal in einem anderen Branch im Workspace... Da hab ich nicht aufgepasst.

Ebenius

 

[ARadauer]

Wie willst du das ohne "break outerloop;" lösen?

die ganze aufgabe in eine methode auslagern und wenn ich gefunden habe, was ich suche mit return zurück....

 

[Noctarius]

die ganze aufgabe in eine methode auslagern und wenn ich gefunden habe, was ich suche mit return zurück....

Klar, man kann das einfach in eine separate methode auslagern, und dort wo das break stehen würde, ein return einfügen, der die spaltennummer ausgibt.

merkte er doch selbst schon an

 

[maki]

Ich habe gerade festgestellt, dass die Weinflasche wider Erwarten schon leer ist. Das erklärt meine unschöne Wortwahl oben. Entschuldigung.

Naja, 6 Pils tragen auch nicht gerade zu Konversation bei (Bäcker und so),also nix für ungut

merkte er doch selbst schon an

Ich habe Andrey so verstanden, dass er keinen guten Namen für die Methode hätte, aber das ist eine frage der kreativität, denn der Ansatz mit auslagern ist richtig imho.

 

[Noctarius]

Naja, 6 Pils tragen auch nicht gerade zu Konversation bei (Bäcker und so),also nix für ungut

Wieso kenn ich das Problem nur?

 

[0x7F800000]

Ich habe Andrey so verstanden, dass er keinen guten Namen für die Methode hätte, aber das ist eine frage der kreativität, denn der Ansatz mit auslagern ist richtig imho.

Ist gut. Mir ist für die version 1.0 des päckchens (also die erste dokumentierte version) sogar ein guter Name für die methode eingefallen. Aber beim basteln des Prototypen war ich dennoch froh, da ein "break label;" schnell hinschmieren zu können, um dann schnell zu spannenderen Sachen überzugehen. Im endgültigen code wird es zwar nicht vorkommen, aber beim nachdenken war es quick&dirty & recht nützlich. Ist das denn nichts?