Java-Problem

Und Pro-Tip:

Vergleiche mit Stringliteralen macht man in Java am besten so rum:

1

  "Irgendeintest".equals(stringVar);

Hat den Vorteil, dass es nicht kracht, wenn stringVar null ist.

Nebenbei: Mich würde es wundern, wenn ein Textfeld ein null-Objekt 
zurück gibt, nur weil kein Text drin steht.

Lars schrieb:
> Im unten stehenden Code möchte ich überprüfen, ob eines oder beide der
> Textfelder "leer" ist.

Dann solltest du das tun bevor du versuchst aus einem "leerem String" 
eine Zahl zu machen und genau das sagt dir der Fehler...

Lars schrieb:
> Leider wirft mir die Konsole laufend Fehler und das Ganze zeigt in der
> Laufzeit null Wirkung

"Die Konsole" wirft überhaupt nix, Java ist nur so nett wenigstens alle 
Fehler um die sich keiner kümmert auf den Standard-Out zu schreiben 
statt mit einem "Core-Dumped" den Dienst zu quittieren.

Lars schrieb:
> obwohl ich leider nicht erkennen kann, wo mein Fehler liegt

Der Fehler liegt daran das man Schrittweise an ein Problem rangeht und 
nicht erst mal einen großen Haufen "ich will" zusammenbaut und dann 
darin versucht rumzustochern was denn nicht so ist wie man sich das 
vorstellt.

Lars schrieb:
>>Dann solltest du das tun bevor du versuchst aus einem "leerem String"
>>eine Zahl zu machen und genau das sagt dir der Fehler...
>
> Na das habe ich doch im Codebeispiel in meinem Eröffnungs-Thread
> gemacht!

Wo genau?

Ich seh im Eröffnungsposting

* das holen von Strings
* das versuchte Konvertieren mittels parseInt in eine Zahl
* die überprüfung ob die Strings leer sind.

Frage: was stimmt an dieser Reihenfolge nicht?
Antwort: es währe wohl vernünftig ZUERST zu testen und erst dann, wenn 
alles in Ordnung ist, zu konvertieren.
Oder hüpfst du zuerst in den Pool und siehst dann erst nach, ob 
überhaupt Wasser im Pool ist? Wohl kaum.

Denn siehe, was sagt dir die Fehlermeldung?
Zuerst mal sagt sie dir, dass das Problem in parseInt aufgetreten ist

1

at java.lang.Integer.parseInt(Unknown Source)

2

             ****************

und sie sagt dir auch, warum parseInt in Probleme gekommen ist:

1

..... For input string: ""

2

                        **

und was daran das Problem ist

1

..... NumberFormatException ....

2

      *********************

Der Input String ist also "" und das ist kein gültiges Format aus dem 
man eine Zahl machen könnte.

Steht alles dort. Du musst nur lesen.

Lars schrieb:
> Ich initialisiere beide String-Variablen "IP_Address" und "Port_temp"
> mit einem String.
> Der Integer-Parse wird ja nicht mal in der IF-Anweisung abgefragt, somit
> ist er völlig nebensächlich.

Dir vielleicht. Dem Rechner nicht.
Da steht eindeutig

1

      String IP_Address = txt_IPAddress.getText();

2

      String Port_temp = txt_Port.getText();

3

      int Port = Integer.parseInt(txt_Port.getText());

4

                 ****************

"versuch den String in eine Zahl umzuwandeln".

Das steht doch dort, oder hab ich was an den Augen?

Wenn das aber dort steht, dann  macht das der Rechner auch. Und zwar 
genau in der Reihenfolge, wie man den Text von oben nach unten liest. So 
ein Compiler ist doch kein Wunderwuzzi, dem du Programmbrocken vorwerfen 
kannst und er sucht sich dann eine genehme Reihenfolge raus.

> In der If-Anweisung frage ich, ob "IP-Address" ODER "Port_temp" keinen
> Wert enthält.

Kannst du.
Ist aber völlig wurscht. weil der Fehler schon 2 Zeilen vorher beim 
parseInt passiert!

Manchmal hat man schon das Gefühl, man muss dem Programmierer auch noch 
die 4 Zeilen Code, die er geschrieben hat, vorlesen :-(

Karl Heinz schrieb:

> Kannst du.
> Ist aber völlig wurscht. weil der Fehler schon 2 Zeilen vorher beim
> parseInt passiert!


Jaa. Reihenfolgen sind wichtig!
Zuerst wird überprüft ob Wasser im Swimmingpool ist und erst dann 
versucht man hinzuhüpfen.
Denn anders rum kann das ins Auge gehen. Und dann hilft es dir auch 
nichts mehr, wenn du dich umsiehst und feststellst dass kein Wasser im 
Pool ist, wenn du bereits mit dem Kopf im Beton steckst.