syntax return-Statement in for schleifen verschiedener if /else-if/else anweisungen
Daniel Kaupp
kann mir einer von euch erklären, warum folgendes nicht geht?
public int beispiel(){
if (1==1){
return 0;
}
else{
for (int i = 0; i < 8; i++) {
if(1==1){
return 0;
}
else if (2 == 2){
return 0;
}
else return 0;
}
}
}
dass in den ifs und returns grad nichts sinnvolles steht soll euch
bitte nicht stören. Meine Frage ist:
Warum reicht es nicht in jedem möglichen Zweig ein return zu haben?
Eine for-schleife terminiert doch in aller Regel (und falls nicht, ist
das überhaupt von Bedeutung?), und mit if und else sind doch alle
Fälle abgedeckt.
Falls sich jemand wundert, was das ganze soll, in einigen Fällen
gibt's im echten Code rekursive Aufrufe.
Bei weiterem Nachdenken kann ich das Teil eigentlich auch als public
void beispiel() machen, da ich die Rückgabewerte eh nicht brauche.
Wenn mir trotzdem jemand die Frage beantworten könnte, wärs super.
Danke
Florian Schaetz
> for (int i = 0; i < 8; i++) {
Überleg dir mal folgendes:
for(;doLoop();)
Wird diese Schleife mind. 1x ausgeführt? Ja? Nein? Möglicherweise? Und
schon hast du den Grund, warum der Compiler davon ausgehen muss, dass
eine for-Schleife 0-n mal durchlaufen wird und nicht 1-n mal.
int doSomething() {
do {
return 0;
while(1 == 0);
}
...reicht übrigens, weil das 1-n mal durchlaufen wird.
Gruß,
Flo
Bernd Eckenfels
> Warum reicht es nicht in jedem möglichen Zweig ein return zu haben?
> Eine for-schleife terminiert doch in aller Regel (und falls nicht, ist
> das überhaupt von Bedeutung?), und mit if und else sind doch alle
> Fälle abgedeckt.
Der Fall dass die for-Schleife terminiert ist nicht abgedeckt. Ansonsten ist
es auch so, dass der java compiler nur bedingt sich die Ausdrucke anschaut
(dead path detection). Der Syntax ist davon aber unabhängig. D.h. auch wenn
er eine Endlosschleife entdeckt darf er danach das return nicht weglassen.
Gruss
Bernd
Daniel Kaupp
Erhard Schwenk
> Daniel Kaupp <daniel...@googlemail.com> writes:
>> Warum reicht es nicht in jedem möglichen Zweig ein return zu haben?
>
> zurückgegeben, da nach Ende der for-Schleife kein Wert
> zurückgegeben wird.
>
> Der Compiler sieht die Werte von Ausdrücken ja nicht.
Das eigentliche Argument ist IMHO, daß der Compiler nicht in jedem Fall
sicher voraussagen kann, ob die for-Schleife terminiert oder nicht (was
wohl dem ganz klassischen Halteproblem entspricht).
--
Erhard Schwenk
Akkordeonjugend Baden-Württemberg - http://www.akkordeonjugend.de/
APAYA running System - http://www.apaya.net/
Claus Reibenstein
> kann mir einer von euch erklären, warum folgendes nicht geht?
Definiere "nicht geht".
> public int beispiel(){
> if (1==1){
> return 0;
> }
Hier ist eigentlich schon Ende, denn 1==1 ist immer true.
> for (int i = 0; i < 8; i++) {
> if(1==1){
> return 0;
> }
> else if (2 == 2){
> return 0;
> }
> else return 0;
> }
Warum eine Schleife? Die wird hier doch schon beim ersten Durchgang auf
jeden Fall per return verlassen.
> dass in den ifs und returns grad nichts sinnvolles steht soll euch
> bitte nicht stören.
Wäre aber besser, wenn dort sinnvoller Code stünde, anhand dessen man
Dein bislang nicht näher spezifiziertes Problem nachvollziehen könnte.
Das, was bis jetzt dort steht, ist nicht mehr als das hier:
public int beispiel() {
return 0;
}
> Warum reicht es nicht in jedem möglichen Zweig ein return zu haben?
Definiere "reicht nicht".
> Falls sich jemand wundert, was das ganze soll, in einigen Fällen
> gibt's im echten Code rekursive Aufrufe.
Kannst Du Deinen echten Code hier mal posten oder - falls er zu
umfangreich ist - ihn auf ein funktionierendes Beispiel reduzieren und
dieses hier posten? Ich vermute nämlich, dass Dein eigentliches Problem
woanders liegt. Möglicherweise löst es sich sogar schon beim Reduzieren
von ganz alleine.
Gruß. Claus
Florian Schaetz
> Kannst Du Deinen echten Code hier mal posten oder - falls er zu
> umfangreich ist - ihn auf ein funktionierendes Beispiel reduzieren und
> dieses hier posten? Ich vermute nämlich, dass Dein eigentliches Problem
> woanders liegt. Möglicherweise löst es sich sogar schon beim Reduzieren
> von ganz alleine.
Sag mal, ist das so ne Art Troll-Versuch? Ich meine, anders kann ich es
mir nicht erklären, dass du so dermaßen am Thema vorbei redest. Vier
andere Leute haben problemlos begriffen worum es geht (nämlich um die
Frage, warum der Compiler bei einem bestimmten Code ein weiteres return
verlangt) und nun kommst du an und schreibst, so leid es mir tut, das
sagen zu müssen, völligen Unsinn.
Gruß,
Flo
Claus Reibenstein
> And thus, Claus Reibenstein wrote...
>
>> Kannst Du Deinen echten Code hier mal posten oder - falls er zu
>> umfangreich ist - ihn auf ein funktionierendes Beispiel reduzieren und
>> dieses hier posten? Ich vermute nämlich, dass Dein eigentliches Problem
>> woanders liegt. Möglicherweise löst es sich sogar schon beim Reduzieren
>> von ganz alleine.
>
> Sag mal, ist das so ne Art Troll-Versuch?
Wie kommst Du denn darauf?
> Ich meine, anders kann ich es
> mir nicht erklären, dass du so dermaßen am Thema vorbei redest.
Wieso rede ich am Thema vorbei?
Daniel hat einen nicht gerade sehr aussagekräftigen Code gepostet, der
"nicht geht", was nun mal keine Fehlerbeschreibung ist. An diesem Code
sind mir einige Dinge aufgefallen, die ich kommentiert habe. Diesen Teil
meines Postings hast Du wohlweislich nicht gequotet.
Inwiefern ist das am Thema vorbei?
> Vier
> andere Leute haben problemlos begriffen worum es geht (nämlich um die
> Frage, warum der Compiler bei einem bestimmten Code ein weiteres return
> verlangt)
Haben sie das? Anhand welchen sinnvollen Codes haben sie das
festgestellt? Und ist das _wirklich_ das Problem?
Vier andere Leute _vermuten_, dass dies das Problem sei.
> und nun kommst du an und schreibst, so leid es mir tut, das
> sagen zu müssen, völligen Unsinn.
Wenn das der Dank dafür ist, dass man zu helfen versucht, werde ich
meine praktischen Erfahrungen, die ich in den letzten 35 Jahren als
Software-Entwickler gesammelt habe, künftig für mich behalten und Euch
alle dumm sterben lassen.
Gruß. Claus
Malte Schirmacher
> Wenn das der Dank dafür ist, dass man zu helfen versucht, werde ich
> meine praktischen Erfahrungen, die ich in den letzten 35 Jahren als
> Software-Entwickler gesammelt habe, künftig für mich behalten und Euch
> alle dumm sterben lassen.
Auf Leute die andere grundsätzlich für dumm halten und obendrein
glauben, dass sie die einzigen sind, die helfen können, kann man getrost
verzichten, ja.
Claus Reibenstein
Vor allem kann man auf Leute verzichten, die Anderen Derartiges grundlos
unterstellen.
Gruß. Claus
Malte Schirmacher
> Vor allem kann man auf Leute verzichten, die Anderen Derartiges grundlos
> unterstellen.
Grundlos? Den Grund für meine Annahme habe ich zitiert.
Michael Paap
> Wenn das der Dank dafür ist, dass man zu helfen versucht, werde ich
> meine praktischen Erfahrungen, die ich in den letzten 35 Jahren als
> Software-Entwickler gesammelt habe, künftig für mich behalten und Euch
> alle dumm sterben lassen.
Putzig. Dann mach's mal gut.
Michael
Florian Schaetz
>> Ich meine, anders kann ich es
>> mir nicht erklären, dass du so dermaßen am Thema vorbei redest.
>
> Wieso rede ich am Thema vorbei?
Wenn jemand eine allgemeine Verständnisfrage stellt und du so
antwortest, als wäre es ein konkretes Problem, das es zu lösen gilt,
dann kann man durchaus sagen, dass es mir so vorkam, als hättest du am
Thema vorbei geredet.
Wenn die Frage sich um Compiler-Verhalten dreht, dann ist die Aussage
"Hier ist eigentlich schon Ende, denn 1==1 ist immer true." wenig
hilfreich, weil sie einfach falsch ist: Für den Compiler ist hier eben
nocht nicht Ende.
> Daniel hat einen nicht gerade sehr aussagekräftigen Code gepostet, der
> "nicht geht", was nun mal keine Fehlerbeschreibung ist. An diesem Code
> sind mir einige Dinge aufgefallen, die ich kommentiert habe. Diesen Teil
> meines Postings hast Du wohlweislich nicht gequotet.
Jup, wohlweislich. Was hätte ich schon sagen sollen? Dass sie nichts mit
der Frage zu tun hatten? Das sie sogar einen expliziten Mangel an
Verständnis aufwiesen? Zum einen Kommentar was zu schreiben hast du mich
ja schon gezwungen, deshalb kann ich ja auch was zum anderen Kommentar
sagen, wenn du unbedingt drauf bestehst:
"Warum eine Schleife? Die wird hier doch schon beim ersten Durchgang auf
jeden Fall per return verlassen."
Wenn die Ursprungsfrage ist, WARUM man nach der Schleife ein return
braucht, dann ist als Antwort "Wieso schreibst du da überhaupt eine
Schleife hin?", kurz gesagt, völlig unsinnig.
> Haben sie das? Anhand welchen sinnvollen Codes haben sie das
> festgestellt?
Anhand des Codes und der danach gestellten Frage.
> Und ist das _wirklich_ das Problem?
> Vier andere Leute _vermuten_, dass dies das Problem sei.
Nachdem selbst der OP (vor deinem Posting) schon wieder gepostet hat und
darin seinen Dank zum Ausdruck gebracht hat, würde ich mal schätzen: Die
vier (oder vielmehr fünf, wenn man den OP mitzählt) haben recht.
> Wenn das der Dank dafür ist, dass man zu helfen versucht, werde ich
> meine praktischen Erfahrungen, die ich in den letzten 35 Jahren als
> Software-Entwickler gesammelt habe, künftig für mich behalten und Euch
> alle dumm sterben lassen.
Persönlich ist es mir völlig egal, aber als guten Ratschlag könnte ich
dir empfehlen, nicht mit solchen dahingeworfenen Sätzen mal schnell alle
anderen Newsgroup-Benutzer als dumm zu betiteln. Und generell hilft es
auch nichts, mit jahrelanger Erfahrung zu prahlen: Wenn du hilfreiche
Postings verfasst, wird man deine Postings zu schätzen wissen, wenn
nicht, dann wird das nicht der Fall sein - in beiden Fällen ist es
völlig belanglos, ob du seit gestern programmierst oder ob dein erstes
"Hello World" auf nem druidischen Steinkreis zu Cäsars Zeiten
programmiert wurde.
Gruß,
Flo
Michael Paap
> Und generell hilft es
> auch nichts, mit jahrelanger Erfahrung zu prahlen: Wenn du hilfreiche
> Postings verfasst, wird man deine Postings zu schätzen wissen, wenn
> nicht, dann wird das nicht der Fall sein - in beiden Fällen ist es
> völlig belanglos, ob du seit gestern programmierst oder ob dein erstes
> "Hello World" auf nem druidischen Steinkreis zu Cäsars Zeiten
> programmiert wurde.
Sehr schön. ;-)
Gruß,
Michael
Bernd Hohmann
> Wieso rede ich am Thema vorbei?
Weil Du Spezialist dafür bist, stets kurze, prägnante und vollkommen
korrekte Antworten zu liefern die aber zu oft nichts mit der
eigentlichen Intension des Fragestellers zu tun haben.
> Wenn das der Dank dafür ist, dass man zu helfen versucht, werde ich
> meine praktischen Erfahrungen, die ich in den letzten 35 Jahren als
> Software-Entwickler gesammelt habe, künftig für mich behalten und Euch
> alle dumm sterben lassen.
Man merkt dass Du noch mehr Jahre auf dem Buckel hast als ich.
Ab einer gewissen Berufserfahrung stören einem die dicken Steine auf dem
Weg nicht mehr - man überrennt oder umgeht sie mit Code wärend der
Nachwuchs erstmal über eine Konstruktion nachdenkt wie man Granit so
kapseln kann dass es nach aussen wie ein Marshmellow aussieht.
Mir lag zum Thema eine ähnliche Antwort wie Deine auf der Zunge, mir
erschien es dann doch am Thema vorbei und so hab ich es gelassen.
Bernd
--
Wenn Frauen nicht wissen was sie machen sollen, ziehen sie sich aus ...
Und wenn Männer nicht wissen, was sie machen sollen, dann schauen sie
sich Frauen an, die nicht wussten, was sie machen sollen ...
Michael Paap
> Mir lag zum Thema eine ähnliche Antwort wie Deine auf der Zunge, mir
> erschien es dann doch am Thema vorbei und so hab ich es gelassen.
Eben. Du verfügst nämlich über deine unerschütterliche
Wald-und-Wiesen-Programmierer-Ignoranz, bist dabei aber nicht 10% so
arrogant wie Claus. Deswegen sind deine Postings problemlos zu ertragen,
oft sogar mit Gewinn, seine hingegen nicht.
Gruß,
Michael
Bernd Hohmann
>> Mir lag zum Thema eine ähnliche Antwort wie Deine auf der Zunge, mir
>> erschien es dann doch am Thema vorbei und so hab ich es gelassen.
>
> Eben. Du verfügst nämlich über deine unerschütterliche
> Wald-und-Wiesen-Programmierer-Ignoranz, [...]
Also den "Wald-und-Wiesen-Programmierer" verbitte ich mir - wenn, dann
bitte "Hausbackener Landprogrammierer"
Und dass Du mir Ignoranz vorwirfst kann ich durchaus verstehen - ich bin
in einem Alter wo nicht mehr die ultimative Tiefe des Verständnis eines
Problems zählt sondern nur noch "wie löse ich es noch vor der
Mittagspause und zwar so, dass es auf Anhieb beim Kunden läuft, ich für
den Rest des Tages in den Wald gehen kann und die Programmierung
nächstes Jahr noch verstehe"
> bist dabei aber nicht 10% so arrogant wie Claus.
Er hat noch nicht innerlich gekündigt - ich schon.
> Deswegen sind deine Postings problemlos zu ertragen,
> oft sogar mit Gewinn, seine hingegen nicht.
Auch Claus wird sich sicherlich alsbald zurückschrumpfen können.
Michael Paap
> Also den "Wald-und-Wiesen-Programmierer" verbitte ich mir - wenn, dann
> bitte "Hausbackener Landprogrammierer"
Ups... das meinte ich doch. Ich kann mir diese Feinheiten nur nie
merken. *g*
> Und dass Du mir Ignoranz vorwirfst kann ich durchaus verstehen - ich bin
> in einem Alter wo nicht mehr die ultimative Tiefe des Verständnis eines
> Problems zählt sondern nur noch "wie löse ich es noch vor der
> Mittagspause und zwar so, dass es auf Anhieb beim Kunden läuft, ich für
> den Rest des Tages in den Wald gehen kann und die Programmierung
> nächstes Jahr noch verstehe"
Das finde ich absolut verständlich, insofern werfe ich dir eigentlich
garnichts vor. Ich finde allerdings ein /bisschen/ mehr Interesse für
die "ultimative Tiefe des Verständnisses" könnte und sollte man sich
meines Erachtens schon bewahren. Aber das ist wirklich nur meine
persönliche Meinung aus der beschützenden Werkstätte eines universitären
Umfelds. ;-)
> Er hat noch nicht innerlich gekündigt - ich schon.
Findest du das nicht selbst wenigstens ein bisschen schade?
Gruß,
Michael
Bernd Hohmann
>> Und dass Du mir Ignoranz vorwirfst kann ich durchaus verstehen - ich bin
>> in einem Alter wo nicht mehr die ultimative Tiefe des Verständnis eines
>> Problems zählt sondern nur noch "wie löse ich es noch vor der
>> Mittagspause [...]"
>
> Das finde ich absolut verständlich, insofern werfe ich dir eigentlich
> garnichts vor. Ich finde allerdings ein /bisschen/ mehr Interesse für
> die "ultimative Tiefe des Verständnisses" könnte und sollte man sich
> meines Erachtens schon bewahren.
Das ist für Anwendungsprogrammierer wie mich (und dazu zählen vermutlich
Kurt und Claus auch dazu) wahnsinnig schwierig weil wir ständig dem
Gesetzgeber und den gesellschaftlichen Anforderungen nachprogrammieren
müssen und dabei die API-Änderungen nicht aus den Augen verlieren dürfen.
Da ist jede wohlgemeinte Änderung oder Erweiterung für uns einfach nur
Stress.
> Aber das ist wirklich nur meine persönliche Meinung aus der
> beschützenden Werkstätte eines universitären Umfelds. ;-)
Ja, das ist wohl die Diskrepanz - aber zumindest Du findest Dich
ausserhalb des universitären Umfelds zurecht (was zb. Stefan Ram
überhaupt nicht kann)
>> Er hat noch nicht innerlich gekündigt - ich schon.
>
> Findest du das nicht selbst wenigstens ein bisschen schade?
Du bist lange genug dabei: Linda ist genauso weg wie Carl und viele
andere, die Java für praktische Anwendungsprogrammierung genutzt haben.
Defacto sind wir nur noch der aussterbende Rest.
Bernd
Jochen Theodorou
[...]
>>> Er hat noch nicht innerlich gekündigt - ich schon.
>>
>> Findest du das nicht selbst wenigstens ein bisschen schade?
>
> Du bist lange genug dabei: Linda ist genauso weg wie Carl und viele
> andere, die Java für praktische Anwendungsprogrammierung genutzt haben.
>
> Defacto sind wir nur noch der aussterbende Rest.
Der aussterbende Rest von Anwendungsprogrammierern die Java nutzen?
Naja, ich bin zu Groovy gegangen, also bin ich theoretisch ja auch
gegangen... vielleicht hast du dann Recht - keine Ahnung.
Gruss theo
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead
http://blackdragsview.blogspot.com/
For Groovy programming sources visit http://groovy.codehaus.org
Bernd Hohmann
>> Defacto sind wir nur noch der aussterbende Rest.
>
> Der aussterbende Rest von Anwendungsprogrammierern die Java nutzen?
Der aussterbende Rest von Anwendungsprogrammierern die hier vertreten sind.
> Naja, ich bin zu Groovy gegangen, also bin ich theoretisch ja auch
> gegangen... vielleicht hast du dann Recht - keine Ahnung.
Groovy ist schön, wäre es vor 15 Jahren aufgetaucht würde ich es als
Hauptsprache nutzen und mir so den einen oder anderen Ärger ersparen.
Glücklich sei der, dessen Projekte entweder klein genug sind (dass er
komplett wechseln kann) oder unabhängig genug sind (dass es keinen stört).
Ich hab hier Nachhang von über 20 Jahren - das will betreut werden.
Wer hat mehr - und in welcher Programmiersprache? ;-)
Jochen Theodorou
[...]
>> Naja, ich bin zu Groovy gegangen, also bin ich theoretisch ja auch
>> gegangen... vielleicht hast du dann Recht - keine Ahnung.
>
> Groovy ist schön, wäre es vor 15 Jahren aufgetaucht würde ich es als
> Hauptsprache nutzen und mir so den einen oder anderen Ärger ersparen.
Ich meine Java mag ja irgendwie schon böse sein, aber man darf nicht
vergessen, dass es das Programmieren sehr vielen mehr geöffnet hat. Erst
dadurch wurde der Leidensdruck der Masse nach über 10 Jahren so groß,
dass man sich Umorientieren wollte, aber ohne die Möglichkeiten von Java
aufzugeben und dann zum Beispiel Groovy herausdestillieren konnte.
> Glücklich sei der, dessen Projekte entweder klein genug sind (dass er
> komplett wechseln kann) oder unabhängig genug sind (dass es keinen stört).
>
> Ich hab hier Nachhang von über 20 Jahren - das will betreut werden.
>
> Wer hat mehr - und in welcher Programmiersprache? ;-)
Das dürfte schwer zu schlagen sein ;)