Unreachable code- Meldung. Warum?

[Roman007]

Hallo,
könnt ihr mal dem Anfänger helfen?
Ich habe folgenden Code:

try 
	{
	 Socket socket = new Socket(host, port);
	 DataInputStream is = new DataInputStream(socket.getInputStream());
     String temp;

         while (true) // lese wiederholt InputStream
              { 
                 temp = is.readLine();					
		         StringTokenizer st = new StringTokenizer(echo);	

		         int T1_X = Integer.parseInt(st.nextToken());
                 //u.s.w.
              }

            is.close();
            socket.close();
         } // try end

      catch
         // u.s.w.

warum meldet Kompiler o.g. Fehler (in der Zeile is.close(), und socket.close())
steht es in der whlie schleife, kein Fehler, aber nach einmaligen Durchlauf, sind is, und socket geschlossen, und das will ich nicht.

[Kenner des Problems]

Mit C++ wär das nicht passiert.

[GPC]

Hallo,

tja, der Code nach der while-Schleife wird NIE erreicht (deshalb unreachable code), denn deine while-Schleife ist eine Endlosschleife. Ich jedenfalls sehe keine Abbruchbedingung. Du?

Formuliere eine adäquate Abbruchbedingung, dann klappt's auch mit dem Code.

MfG

GPC

[Skogsrädd]

Weil das ne Endlosschleife ist. Die Bedinung ist immer erfüllt und deswegen wird der Schleifenrumpf nie verlassen -> die folgenden Zeilen werden nie erreicht.

[GPC]

Kenner des Problems schrieb:

Mit C++ wär das nicht passiert.

Stimmt, du hättest das Problem erst beim Testen entdeckt...

[anmerkung]

GPC schrieb:

Kenner des Problems schrieb:

Mit C++ wär das nicht passiert.

Stimmt, du hättest das Problem erst beim Testen entdeckt...

Troll

[Sgt. Nukem]

Bei while(false) kommt der Hinweis übrigens nicht. ... Jedenfalls nicht für die genannten Befehle...

[Roman007]

danke für die Hilfe,
ist mir nicht aufgefallen,dass der Fehler wegen der Schleife kommt.
Ich dachte, hat was mit dem InputStream zu tun, weil der Compiler an der Stelle anhält
Es war nur ein versuch, so etwas zu programmieren.
Eigentlich will ich ein Applet programmieren, der vom Server (in c++ geschrieben) die Simulationsdaten kontinuerlich empfängt.

Hat jemand passenden Code für einem Client, der nach dem Verbindungsaufbau in der Schleife die Daten empfängt, und sich terminiert, wenn Applet geschlossen wird?

Grüße

[Gregor]

anmerkung schrieb:

GPC schrieb:

Kenner des Problems schrieb:

Mit C++ wär das nicht passiert.

Stimmt, du hättest das Problem erst beim Testen entdeckt...

Troll

Warum Troll? Ich habe es gerade mit dem g++ ausprobiert. Der kompiliert ein Codestück wie das folgende ganz ohne irgendwelche Warnungen oder so:

#include <iostream>

int main()
{
   while (true){}
   std::cout << "Hallo" << std::endl;
}

Das äquivalente Codestück unter Java kompiliert nicht. Gibt es einen Grund dafür, warum der g++ das so einfach annimmt? Vermutlich kann man da irgendwie das "Warnlevel" anheben, oder? Wie heißt denn da der entsprechende Schalter für den Compiler?

Bei while(false) kommt der Hinweis übrigens nicht. ... Jedenfalls nicht für die genannten Befehle...

Also ich weiß ja nicht, welchen Compiler du nutzt, aber bei mir kompiliert das entsprechende Codestück mit while(false) auch nicht:

public class Unreachable
{
   static void main(String[] args)
   {
      while(false)
      {
         System.out.println("Hallo!");
      }
   }
}

Da gibt es folgenden Fehler:

gregor@linux:~/JavaProjects/Test/UnreachableTest> /usr/java/jdk1.6.0/bin/javac Unreachable.java
Unreachable.java:6: unreachable statement
      {
      ^
1 error

Das ist allerdings auch ein Java 6.0-Snapshot javac. Vielleicht wurde das in früheren Compilern nicht als Fehler gefunden.

[Sgt. Nukem]

Meine Grinsebacke übersehen...

Gregor schrieb:

Bei while(false) kommt der Hinweis übrigens nicht. ... Jedenfalls nicht für die genannten Befehle...

Also ich weiß ja nicht, welchen Compiler du nutzt, aber bei mir kompiliert das entsprechende Codestück mit while(false) auch nicht:

public class Unreachable
{
   static void main(String[] args)
   {
      while(false)
      {
         System.out.println("Hallo!");
      }
   }
}

Da gibt es folgenden Fehler:

gregor@linux:~/JavaProjects/Test/UnreachableTest> /usr/java/jdk1.6.0/bin/javac Unreachable.java
Unreachable.java:6: [b]unreachable statement[/b]

Sgt. Nukem schrieb:

Bei while(false) kommt der Hinweis übrigens nicht. ... Jedenfalls nicht für die genannten Befehle...

[GPC]

anmerkung schrieb:

GPC schrieb:

Kenner des Problems schrieb:

Mit C++ wär das nicht passiert.

Stimmt, du hättest das Problem erst beim Testen entdeckt...

Troll

Ja klar, Laufzeitfehler sind mir auch enorm lieber als Compilerfehler/warnungen. Die sind viel eindeutiger, und auch nicht so schlimm, wenn sie bei der Präsentation des Programms auf einmal auftreten lol

Warum sollte ich mich um sowas kümmern? Der Compiler hat mehr Zeit als ich.

Vermutlich kann man da irgendwie das "Warnlevel" anheben, oder? Wie heißt denn da der entsprechende Schalter für den Compiler?

Nö, kann man afaik nicht, du kannst alles möglich warnen lassen, aber das anscheinend nicht, jedenfalls hat die manpage nichts in diese Richtung hergegeben.

Ich hab mal

#include <iostream>

int main() {
  while (1);

  std::cout<<"SCRRRREEAM!!\n";

  return 0;
}

via

bash-3.00$ g++ -W -Wall -O2 -Os -o main main.cpp
bash-3.00$ ./main

bash-3.00$

kompiliert und ausgeführt. Na ja, er hat jedenfalls nichts bemängelt.

MfG

GPC

[Gregor]

Nutzt man unter C++ solche Arten von "Schaltern" eigentlich für Debug-Versionen? Oder gibt es andere Gründe, warum nicht erreichbarer Code unter C++ durchaus normal ist?

[GPC]

Gregor schrieb:

Nutzt man unter C++ solche Arten von "Schaltern" eigentlich für Debug-Versionen?

Ich versteh zwar die Frage nicht, aber der bevorzugte Schalter zum Debuggen ist beim g++ der

-g

, der kommt dann bei der Release-Version weg, die Warnlevel bleiben(die Optimierung oben kann man sich beim Debuggen ja auch schenken). Ich jedenfalls hab die Warnlevel immer drin, und noch ein paar mehr, wenn mir der Compiler schon die Unterstützung bietet, nehme ich sie auch gerne in Anspruch.

Oder gibt es andere Gründe, warum nicht erreichbarer Code unter C++ durchaus normal ist?

Mir fällt kein vernünftiger ein. Aber vllt. kickt der Compiler das als "wegoptimierbarer" Code gleich in die Tonne

MfG

GPC

[Gregor]

GPC schrieb:

Gregor schrieb:

Nutzt man unter C++ solche Arten von "Schaltern" eigentlich für Debug-Versionen?

Ich versteh zwar die Frage nicht, [...]

Naja, das bezog sich darauf, dass man ja manchmal gewisse Ausgaben beim Debuggen haben möchte. Da hat man dann vielleicht schonmal ein Konstrukt der folgenden Art:

if(DEBUG) ausgabe;

Wobei DEBUG dann vielleicht eine boolsche Konstante ist bzw. über den Präprozessor definiert ist oder so.

Wenn man so ein "DEBUG" über den Präprozessor definiert, dann hat man da für den Compiler durchaus ein "if(false) ausgabe;" stehen und somit unerreichbaren Code. Aber vielleicht macht man das unter C++ ja auch ganz anders: Komplett über den Präprozessor zum Beispiel.

[Gast]

Gregor schrieb:

Nutzt man unter C++ solche Arten von "Schaltern" eigentlich für Debug-Versionen? Oder gibt es andere Gründe, warum nicht erreichbarer Code unter C++ durchaus normal ist?

In C++ ist es oft üblich, in einer while( true ) Schleife durch ein Array zu iterieren und beim letzten Element dann durch die Exception bei der Indexprüfung abzubrechen, was das Verhalten dieses Compilers erklärt. Der Code darunter ist nur scheinbar nicht erreichbar.

Naja ernsthaft, der g++ ist halt einfach schlecht. Ich hab auch mal sowas gehabt:

if( abs(a > 5)   &&   abs(b > 5) ) ...

Beim VC++ hättest du in beiden Fällen sofort ne Warnung.

[TriPhoenix]

$ g++ -Wunreachable-code test.cpp
test.cpp: In function `int main()':
test.cpp:6: warning: will never be executed
test.cpp:6: warning: will never be executed
test.cpp:6: warning: will never be executed
test.cpp:6: warning: will never be executed

Klappt wunderbar, wenn man nur den richtigen Schalter benutzt

[Gast]

Heißt -Wall jetzt neuerdings nicht mehr "alle Warnungen"?

[Gregor]

Optimizer schrieb:

In C++ ist es oft üblich, in einer while( true ) Schleife durch ein Array zu iterieren und beim letzten Element dann durch die Exception bei der Indexprüfung abzubrechen, was das Verhalten dieses Compilers erklärt. Der Code darunter ist nur scheinbar nicht erreichbar.

Dieses "Design-Pattern" hast du dir doch jetzt aus meinem Javacode geklaut. ...der übrigens fehlerfrei kompiliert, obwohl es da ein "while(true)" ohne "break;" drin gibt. :p hmmm... glaub ich zumindest. Ich weiß gar nicht, ob ich das überhaupt ausprobiert habe.

[Gast]

Ehrlich gesagt glaube ich nicht, dass er fehlerfrei compiliert. Ich würde vermuten, dass der Compiler nur checked Exceptions bei der Kontrolfluss-Analyse berücksichtigt.

[Gregor]

Optimizer schrieb:

Ehrlich gesagt glaube ich nicht, dass er fehlerfrei compiliert. Ich würde vermuten, dass der Compiler nur checked Exceptions bei der Kontrolfluss-Analyse berücksichtigt.

Da:

gregor@linux:~/JavaProjects/Test> cat AntiPattern.java
public class AntiPattern
{
   public static void main(String[] args)
   {
      int [] array = new int[100000];
      int a = 0;
      try
      {
         int i = 0;
         while(true) //Hier spar ich mir ganz viele Bereichsprüfungen.
         {
            array[i] = i;
            a += array[i];
            ++i;
         }
      }
      catch (ArrayIndexOutOfBoundsException e)
      {
         // Das hier ist die Abbruchbedingung für die Schleife.
      }
      System.out.println(a);
   }
}
gregor@linux:~/JavaProjects/Test> /usr/java/jdk1.6.0/bin/javac AntiPattern.java
gregor@linux:~/JavaProjects/Test> /usr/java/jdk1.6.0/bin/java AntiPattern
704982704