✔ Array: Feststellen ob nächstes Element existiert?

[Vereth]

Natürlich kann darauf verzichtet werden, und nahezu jede Exception kann durch vorherige Prüfung vermieden werden. Und dass mir die length-Eigenschaft die notwendige Information liefern kann, weß ich auch. Aber ich wollte zeigen, dass Exceptions nicht einfach etwas sind, was man meiden muss, sondern etwas, was man nutzen kann, um den Code kürzer und damit auch überschaubarer (manche würden sogar sagen: lesbarer) zu machen. Prüfungen auf Gültigkeit der Daten können ziemlich umständlich und teilweise auch fehlerträchtig sein, eine Exception ist dann bisweilen einfacher zu handhaben und zu verstehen. Außerdem: bei jedem Array-Zugriff wird von der VM geprüft, ob man den Datenbereich auch nicht verlässt. Warum doppelt moppeln und es selber auch noch tun? Die VM hat ein bisserl was weniger zu tun, und den Code macht es kürzer und prägnanter.

 

[vfl_freak]

Moin,

offen gestanden sehe ich das Problem nicht

String data = "hallo ich bin dein test string";
String a[];
a = data.split(" ");
// also enthält das Stringarray 'a' jetzt 6 Elemente
// sprich: a.length == 6

// also Schleife von a[0] bis a[5]
for( int i = 0; i < a.length; i++ ) 
{
    System.out.println( "a[" + i + "]: " + a[i] );
}

Warum sollte ich jetzt - auf welche Art und Weise auch immer - prüfen wollen, ob es nicht doch mehr als 6 Elemente sind
Sollte mein Stringarray bspw. jedoch 10 Elemente haben, dann läuft die Schleife halt von 0 .. 9
Wo ist hier ein Problem

Gruß
Klaus

 

[lui7172]

Ich hätte einfach geschrieben

try { System.out.println(String.format("--%s%s--", a[5], a[6])); }
catch ( ArrayIndexOutOfBoundsException e ) {}

Warum etwas prüfen, was vom System sowieso geprüft wird?

Ich bin ja auch ein Freund von Exceptions, aber mehr den geworfenen, als den verworfenen. In diesem Fall halte ich es nicht für angebracht, da Du Dich ohne Not einer Möglichkeit der Runtimefehlerfindung beraubst. Denn hier ging es auschließlich um a[6]. Wenn auch a[5], aus welchem Grunde auch immer, eine Exception wirft, so kannst Du das erst mal nicht unterscheiden. In dem einen Fall mag es OK sein, in dem anderen nicht.

 

[Vereth]

Im Prinzip hast du recht, aber das betrifft wohl mehr die Entwicklungsphase. Außerdem sind die Werte 5 und 6 eher exemplarisch zu sehen. Wer jedoch ein Array sequentiell durchlaufen möchte (was man allerdings meistens zu vermeiden trachtet), sollte statt

for( int i = 0; i < a.length; i++ )
{
    System.out.println( "a[" + i + "]: " + a[i] );
}

besser

try { for( int i = 0; ; i++ )
{
  System.out.println( "a[" + i + "]: " + a[i] );
} } catch ( ArrayIndexOutOfBoundsException e ) {}

schreiben. Das ist effizienter, weil man dann pro Schleifendurchlauf eine Objektreferenz weniger aufzulösen hat (was zugegebenermaßen oft nicht ins Gewicht fällt).
Aber diese Entscheidung stellt sich mir sowieso kaum, weil ich fast immer Collections verwende. Die haben nämlich alle einen Iterator, den ich mit dem erweiterten for nutzen kann.

 

[lui7172]

Hm, ab Java 5 würde ich generell

for( int item : a ) { ... }

wählen, wenn irgendwas über das ganze Array laufen soll. Da braucht es keine Collection für.
Und eine Exception als Abbruchbedingung ist ja ganz fürchterlich.

 

[vfl_freak]

Und eine Exception als Abbruchbedingung ist ja ganz fürchterlich

Das sehe ich allerdings auch so
Wenn ich denn schon eine FOR-Schleife sein muss und ich die konkrete Bedingung kenne (hier also die Anzahl Elemente im Array), dann gibt es IMHO aber auch gar keinen Grund, diese Bedingung nicht zu nutzen .....

Gruß
Klaus

 

[Anime-Otaku]

try { for( int i = 0; ; i++ )
{
  System.out.println( "a[" + i + "]: " + a[i] );
} } catch ( ArrayIndexOutOfBoundsException e ) {}

schreiben. Das ist effizienter, weil man dann pro Schleifendurchlauf eine Objektreferenz weniger aufzulösen hat (was zugegebenermaßen oft nicht ins Gewicht fällt).
Aber diese Entscheidung stellt sich mir sowieso kaum, weil ich fast immer Collections verwende. Die haben nämlich alle einen Iterator, den ich mit dem erweiterten for nutzen kann.

Da kann ich mich doch nicht zurückhalten meine Meinung dazu abzugeben. Ich hoffe ich bin nicht zu drastisch mit meinen Aussagen.

1. Ein bekanntes Zitat: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.". [Donald Knuth]

2. Ich muss dir widersprechen, der Code wird nicht lesbarer, eher das Gegenteil. (Vlt. auch weil man die alte Vorgehensweise gewöhnt ist)

3. Exceptions, sollten eine Ausnahme sein (wie der Name schon sagt) und nicht der Regelfall.

4. Mit der Exception erzeugst du ein neues Objekt, welches dein Performance-Gewinn wahrscheinlich wieder zu Nichte machst.

5. Eine andere Optimierung, welche in einem Foreach bei einem Array schon gemacht wird ist folgende:

for (int i = 0, size= array.length; i < max;i++) {
....
}

Dadurch wird array.length nur einmal aufgerufen. Da das aber für viele ungewohnt ist und keine nennenswerte Performance bringt ist das nicht zu empfehlen.

Ich hoffe du bist mir wegen meinen Ausführungen nicht böse

 

[Vereth]

Da sieht man mal wieder, zu welcher Konfusion eine Anhäufung von Hilfsvariablen führt. Da hat doch glatt wieder jemand sich nicht entscheiden können, ob er sie size oder max nennen soll. Und die Schleife war noch nicht mal geschachtelt. Mit meiner Methode wäre einem das erspart geblieben.

 

[Biergamasda]

Ok, ich kann auch nicht drum rum mal meine Meinung zu dem Thema kund zu tun

Verfolge das ganze schon ein Weilchen

for(int i = 0; i < array.length; i++) {
//...
}

Gegen diese Variante ist rein gar nichts einzuwenden.
Mit einem guten Compiler wird array.length nicht jedes mal referenziert sondern in register gelegt, genauso wie's i (is zumindest bei C so, wieso sollts von der Java Runtime anders sein)
array.length ist sowieso ein feld, und keine Methode. Demnach habe ich einfach eine Referenz auf eine Speicheraddresse was performancce technisch komplett irrelevant ist, da es sowieso im Cache ist.

und nun zu der exception

try { 
    for( int i = 0; ; i++ ) {
        System.out.println( "a[" + i + "]: " + a[i] );
    }
} catch (ArrayIndexOutOfBoundsExceptione ) {}

mal ehrlich - was soll das?
Klar könnte man es so machen, aber was is daran bitte lesbar oder effizient?
Performance technisch kann ich mir nicht vorstellen, dass hier ein Vorteil erzielt wird, Man hat zusätzliche Objekte die man erstellt. Demnach mehr Daten die in den Cache geladen werden müssen... also eher sinnfrei


Exceptions sind eine super Erfindung, und natürlich kann und soll man diese benutzen... aber bitte... hört auf krampfhaft irgendwas zweckentfremden zu wollen.

Gruß