String.substring problem

Conners

Erfahrenes Mitglied
Hallo
Ich hab in meiner XPath-Funktion unter anderem eine Stelle wo ich aus einem Tag einen String auslese und diesen aufteilen will.

Angenommen der Tag würde so aussehen
Code:
<test>54356 Hallo</test>
Ich führe folgenden Code aus.

Code:
List<Element> myxmllist = XPath.selectNodes( doc, "category/details" );
...
XPath test = XPath.newInstance("entry/test/text()");
...
for(Element details : myxmllist)
{
...
String x = test.valueOf(details);
String y = x.substring( x.indexOf(' ') + 1  );
String z = x.substring(0, x.indexOf(' '));
...
Wieso kann ich den String y erstellen, aber beim String z kommt ne Fehlermeldung.
Code:
Die XML-Seite kann nicht angezeigt werden 
Die XML-Eingabe kann nicht angezeigt werden, wenn Stylesheet XSL verwendet wird. Beheben Sie den Fehler und klicken Sie dann auf Aktualisieren, oder wiederholen Sie den Vorgang später. 


--------------------------------------------------------------------------------

Die folgenden Tags wurden nicht geschlossen: list, entry, st. Fehler beim Bearbeiten der Ressource 'http://localhost/server...

List und Entry wurden übrigens beide normal geschlossen.


Weiß das jemand? Oder hab ich schon wieder irgendwo Unfug gemacht ?
 
Die Fehlermeldung ist so aussagekräftig wie nichts....das einzigste was wir dadurch erfahren konnten, dass es sich dabei um eine Webanwendung handelt.
Die wahrscheinlich abbricht und deswegen die angefangen Tags nicht geschlossen werden.

Woher weißt du zum Beispiel, dass es beim String z passiert?
Ich würde gerne mal die richtige Fehlermeldung sehen....wenn es denn eine gibt...:suspekt:

So das waren meine 2 Cents dazu^^
 
Wenn ich die Zeile wo ich den String z initialisiere auskommentiere klappt meine Anwendung wunderbar. Starte ich die Anwendung mit nicht auskommentierter Zeile "String z = .." kommt im browser die eben geschriebene Fehlermeldung.
 
Hab ich mir auch schon überlegt. Hab alle Zeilen Code wo z benutzt weggemacht, solange bis z unterschlängelt war, also nicht im Code verwendet wird.
Es kam trotzdem der Fehler.

Gibt es eine andere Möglichkeit an den vorderen Teil des Strings zu kommen?
Ich kann ja den Code auch noch ändern, ist ja nicht so, dass meine Lösung unbedingt verwendet werden muss.

Gruß
Conners
 
Lass dir doch z mal ausgeben.

Ich mein irgendwas wirst du mit z ja noch machen, weil von einem Substring gibts doch keinen Fehler.
 
Das ist ja das Problem.
Ich hab da nur folgendes stehen:

Code:
String z;
z = x.substring(0, fs.indexOf(' '));

z ist in Eclipse gelb unterschlängelt, was bedeutet, dass diese lokale Variable nie in dem Code gelesen wird. D.h. der Fehler entsteht durch die Initialisierungscodezeile.

Ich hab mir mal alle x´s die vorkommen ausgeben lassen.
Die sehen in etwa so aus:

Zahl Name1 Name2 Name3

2 Elemente haben keine Zahl davor, aber die würd ich extra rausfiltern, wenn z sich nicht intparsen lassen würde.

Aber, wodran es evtl. auch noch liegen kann. Ein entry hat in dem xml-File kein x-String. Der fehlt, was auch richtig ist. Könnte das dadran liegen? Aber wenns dadran liegt, wieso kann ich dann y initialisieren?
 
Mit etwas nachdenken biste doch noch auf das Problem gekommen....

Das Ergebnis eines indexOf sollte man immer prüfen, wenn nichts gefunden wird. Nämlich dann liefert er -1. Was bei y nicht das Problem ist, denn hier wird durch das +1 eine 0 daraus was wiederum dann zu was gescheitem zeigt.

Aber bei z versuchst du dann von 0 bis -1 einen String heraus zu ziehn, wenn das leere Zeichen in dem String nicht gefunden wird, was natürlich nicht gehen kann. Also fliegt eine ArrayIndexOutOfBoundException, welche hätte man diese schon vorher gesehen klarer wäre was passiert.
 
Das ist eine der sog. RuntimeExceptions (wie NullPointerException auch), welche sich in der Regel erst zur Laufzeit bemerkbar machen und normalerweise durch gescheite Prüfung der Daten umgangen werden können.

Bei Gui Programmen ist es teilweise sinnvoll mal generell alle Exceptions am Ende der nach Oben Werfkette abzufangen, um diese dann für den Anwender/Entwickler entsprechend ausgeben zu können.
Allerdings sollte man trotzdem immer schauen, das man alle möglichen Programmwege abgedeckt hat. Eine fliegende Exception ist immer unschön.
 
Zuletzt bearbeitet:
Zurück