break block by label

Status
Nicht offen für weitere Antworten.
D

didjitalist

Bekanntes Mitglied
ich entwickel schon ziemlich lange java, aber mir ist grad erst folgendes sprachkonstrukt aufgefallen:
Code:
BLOCK:
{
  // do stuff
  if( someCondition )
  {
    break BLOCK;
  }
  // more code
}
// wee, BLOCK exited prematurely!
ist das in den java konventionen so vorgesehen? erscheint mir irgendwie unsauber.
 
0x7F800000

0x7F800000

Top Contributor
ist das in den java konventionen so vorgesehen?
könnte es denn sonst kompilieren?
erscheint mir irgendwie unsauber.
Es wird praktisch nirgends verwendet. Habe nie im Leben ein Stück "echten" code gesehen, wo sowas angewandt wurde. Da das verhalten ähnlich verwirrend wie bei GOTO ist, sollte man dieses konstrukt vermeiden bzw. 20 mal überlegen, bevor man es einsetzt (an dieser Stelle sollte maki auftauchen, und sagen, dass man da nichts zu überlegen braucht, und dass diese labels absolut verboten gehören ;) , es gab schon 2-3 megalange philosophische Threads zu diesem Thema, fazit: "lass es lieber")
 
D

didjitalist

Bekanntes Mitglied
könnte es denn sonst kompilieren?
ich glaube nicht an die unfehlbarkeit von compiler implementierungen ;)

sehe in produktivcode öfters mal konstrukte, die ein halbes GOTO ersetzen sollen ( bspw. do{ ... }while(false); ), aber das mit den labels war mir neu. fand schon die do/while konstrukte gruselig, aber das mit den labels eröffnet ja ganze andere dimensionen nicht mehr nachvollziehbaren codes. glaub ich werd mal schnell paar coding conventions anpassen.
 
Wildcard

Wildcard

Top Contributor
Damit sich etwas java compiler nennen darf (und davon gibt es ja zig), muss er endlose Tests und Zertifizierungen über sich ergehen lassen. Fehler im Compiler selbst, sind da sehr sehr sehr unwahrscheinlich.
 
D

didjitalist

Bekanntes Mitglied
mach "bei sun" draus und ich unterschreibs. hab in der vergangenheit aber die erfahrung machen müssen, dass man gegen andere compiler implementiert, wie beispielsweise eclipse, und der sun compiler deinen code plötzlich nicht mehr mag.
 
Wildcard

Wildcard

Top Contributor
mach "bei sun" draus und ich unterschreibs. hab in der vergangenheit aber die erfahrung machen müssen, dass man gegen andere compiler implementiert, wie beispielsweise eclipse, und der sun compiler deinen code plötzlich nicht mehr.
Plötzlich nicht mehr... was? Der IBM Compiler arbeitet korrekt, oder kannst du ein Gegenbeispiel nennen?
Und seit wann implementiert man gegen einen Compiler?
 
D

didjitalist

Bekanntes Mitglied
Und seit wann implementiert man gegen einen Compiler?
ehrlich gesagt ist da eclipse das einzige beispiel, das ich nennen kann. und dabei speziell die mit java 1.5 eingeführten enums. die eclipse jungs haben offensichtlich die initialisierungsreihenfolge bei enums anders gelöst, als sun, weshalb die jdk compiler "eclipse" code u.U. nicht mehr mochten.

ist allerdings auch mein einziges beispiel für java compiler diskrepanzen, also eigentlich vernachlässigbar.
 
Wildcard

Wildcard

Top Contributor
ehrlich gesagt ist da eclipse das einzige beispiel, das ich nennen kann. und dabei speziell die mit java 1.5 eingeführten enums. die eclipse jungs haben offensichtlich die initialisierungsreihenfolge bei enums anders gelöst, als sun, weshalb die jdk compiler "eclipse" code u.U. nicht mehr mochten.

ist allerdings auch mein einziges beispiel für java compiler diskrepanzen, also eigentlich vernachlässigbar.
Da du einem Sun Compiler kein Compilat fütterst, sondern Quelltext, macht das so keinen Sinn. Da musst du jetzt aber schon ein sehr konkretes Beispiel auf den Tisch pflanzen, das ich dir abnehme, das der IBM Compiler ein Programm akzeptiert, das der Sun Compiler nicht akzeptiert, sofern Compliance Level, Java Version, Compiler Flags,... identisch waren.
 
D

didjitalist

Bekanntes Mitglied
Code:
public enum Foo
{
  BLARGH( 0 );
  
  private static List<Integer> values;
  
  private Foo( int value )
  {
    if( values == null )
    {
       values = new ArrayList<Integer>();
    }
    values.add( Integer.valueOf( value ) );
  }
}
 
Wildcard

Wildcard

Top Contributor
Witzige Sache. Scheint mehr ein Bug in der JLS gewesen zu sein.
Mit Suns javac für Java 5 ist das kompilierfähig und wurde dann geändert (wirft mit suns javac für Java 6 also einen Fehler).
Bei Eclipse dann analog, funktioniert mit Eclipse 3.3, funktioniert nicht mit Eclipse 3.4.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=228109
 
D

didjitalist

Bekanntes Mitglied
konkret wurde das problem mal, nachdem jemand unseren build server upgedatet hatte. denk mal der schelm hatte dann klammheimlich nen java 6 compiler im 1.5 compilance mode installiert, ohne mir bescheid zu sagen. ansonsten wärs ja nicht zu erklären.
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen
  Titel Forum Antworten Datum
S Methoden "Unschöne" Break-Anweisung aus verschachtelter Funktion entfernen Allgemeine Java-Themen 11
O while - Schleife unterbrechen mit break; Allgemeine Java-Themen 5
meez nix continue und break Allgemeine Java-Themen 19
M NamingService break down Allgemeine Java-Themen 2
I Java Optionals mit return-Block Allgemeine Java-Themen 2
C try-catch Block Verständnisfrage Allgemeine Java-Themen 14
B Sudoku-Block-Prüfung Allgemeine Java-Themen 1
P Threads Objekt im Konstruktor anders wie im Run()-Block Allgemeine Java-Themen 10
C Unendlich Wiederholungsfehler bei try catch - Block Allgemeine Java-Themen 3
T Warum ein privileg block? Allgemeine Java-Themen 0
H Probleme mit finally-Block und close() Allgemeine Java-Themen 4
N String aus Try/Catch-Block übernehen Allgemeine Java-Themen 14
B Execption auf Oberfläche werfen, try-catch-Block Allgemeine Java-Themen 6
G Initialization Block? Allgemeine Java-Themen 8
A Annotation einer Subklasse im static-Block auslesen. Allgemeine Java-Themen 6
E JNA:Zugriff auf Common-Block von Fortran bzw. Struct in C Allgemeine Java-Themen 2
J synchronized block mit this und wait() Allgemeine Java-Themen 5
M Konstruktor / statischer Block Allgemeine Java-Themen 13
G URLClassLoader stößt static Block nicht an Allgemeine Java-Themen 8
G GC Warning: Repeated allocation of very large block Allgemeine Java-Themen 35
E try/catch Block um ganzes Programm Allgemeine Java-Themen 10
conan2 static-Block in Klassen Allgemeine Java-Themen 6
H Ein synchronized Block ausreichend? Allgemeine Java-Themen 6
T rießiger try - catch - Block Allgemeine Java-Themen 13
B Long in einen Double umwandeln und im Label anzeigen Allgemeine Java-Themen 7
V USB Label Drucker Allgemeine Java-Themen 7
L Label- & Textfelderzeugung durch Button Allgemeine Java-Themen 1
M Swing JFreeChart Domain Axis Label Abstand zu TickUnitLabel Allgemeine Java-Themen 9
S AWT JFreeChart in ein Label Allgemeine Java-Themen 7
M Probleme mit String in Label übergeben. Allgemeine Java-Themen 6
S Text in for Schleife in Label einfügen Allgemeine Java-Themen 4
P ActionListener / Label Name auslesen Allgemeine Java-Themen 2
N String array in Label ausgeben Allgemeine Java-Themen 6
MQue Anzeige mit Label kombinieren Allgemeine Java-Themen 4
S Bild durchs Label laufen Allgemeine Java-Themen 14
K bildflackern in label Allgemeine Java-Themen 2
7 Mehrzeiliges Label Allgemeine Java-Themen 16
H Nullpointer exception, Attribute in Label schreiben? Allgemeine Java-Themen 4
S Probleme mit LinkedList und Label mit gridbagLayout Allgemeine Java-Themen 2
H set. in label ausgeben ? Allgemeine Java-Themen 2
G Text und Bild/Icon im Label/Button positionieren/ausrichten Allgemeine Java-Themen 2
J Zeitzähler in Label? Allgemeine Java-Themen 6
M Bild auf Label. Allgemeine Java-Themen 8
L Label mit Images Allgemeine Java-Themen 20

Ähnliche Java Themen

Anzeige

Neue Themen


Oben