Discussion:
Thread.sleep() hält den Thread nicht an
(zu alt für eine Antwort)
Ralf Schneider
2020-07-17 14:00:36 UTC
Permalink
Hallo zusammen,
ich versuche gerade einen Thread schlafen zu lassen, jedoch funktioniert
das nicht. Die Ausführung hält da nicht an und rast durch. Ich arbeite
mit Eclipse aus Entwicklungsumgebung. Hat jemand eine Idee, was ich
dagegen tun kann ?


while (socket.isConnected() == false) {
try {
socket.connect(isa);
Thread.sleep(1000000);
}
catch(InterruptedException ie) {
//ie.printStackTrace();
}
catch (ConnectException ce) {
}
catch (SocketException se) {
// se.printStackTrace();
}
catch (UnknownHostException uhe) {
// uhe.printStackTrace();
}
catch (IOException ioe) {
// ioe.printStackTrace();
}
System.out.println("Verbinde...");
} u.s.w.

Gruß
Ralf
--
http://www.kr-db.de
Michael Paap
2020-07-17 14:08:50 UTC
Permalink
Post by Ralf Schneider
ich versuche gerade einen Thread schlafen zu lassen, jedoch funktioniert
das nicht. Die Ausführung hält da nicht an und rast durch.
Ich erlaube mir, zu zweifeln.
Post by Ralf Schneider
Ich arbeite
mit Eclipse aus Entwicklungsumgebung. Hat jemand eine Idee, was ich
dagegen tun kann ?
while (socket.isConnected() == false) {
Schöner:

while(! socket.isConnected() {
Post by Ralf Schneider
try {
socket.connect(isa);
Thread.sleep(1000000);
}
catch(InterruptedException ie) {
//ie.printStackTrace();
Ändere mal alle Catch-Blöcke so, dass ein Stacktrace ausgegeben wird.
Wahrscheinlich kommt dein Code gar nicht erst bis zur Sleep-Anweisung,
sondern es wird in connect() eine Exception ausgelöst, von der du nichts
mitbekommst. Leere Catch-Blöcke sind eine ganz schlechte Idee.

Gruß
Michael
Ralf Schneider
2020-07-17 18:03:43 UTC
Permalink
Post by Michael Paap
Post by Ralf Schneider
ich versuche gerade einen Thread schlafen zu lassen, jedoch
funktioniert das nicht. Die Ausführung hält da nicht an und rast durch.
Ich erlaube mir, zu zweifeln.
Post by Ralf Schneider
Ich arbeite mit Eclipse aus Entwicklungsumgebung. Hat jemand eine Idee,
was ich dagegen tun kann ?
while (socket.isConnected() == false) {
while(! socket.isConnected() {
Post by Ralf Schneider
try {
socket.connect(isa);
Thread.sleep(1000000);
}
catch(InterruptedException ie) {
//ie.printStackTrace();
Ändere mal alle Catch-Blöcke so, dass ein Stacktrace ausgegeben wird.
Wahrscheinlich kommt dein Code gar nicht erst bis zur Sleep-Anweisung,
sondern es wird in connect() eine Exception ausgelöst, von der du nichts
mitbekommst. Leere Catch-Blöcke sind eine ganz schlechte Idee.
Gruß Michael
Es wird geworfen:

Verbinde...
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect
(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress
(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect
(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:607)
at Newsfeed.senden(Newsfeed.java:57)
at Newsfeed.main(Newsfeed.java:42)
Verbinde...
java.net.SocketException: Socket closed .............. usw. hunderte Male.

Ich habe natürlich keine Ausgaben gemacht, da es unsicher ist, dass
verbunden wird. Es ist noch niemand da, der etwas empfangen kann. Also
würde ich gerne ein paar Sekunden warten und es dann noch einmal
versuchen.

Ich sehen, dass Thread.sleep(1000) nicht erreicht wird, aber ich fand
keine Methode das zu verhindern. Auch ein Timeout bewirkt keine Besserung.

Gruß
Ralf
--
http://www.kr-db.de
Michael Paap
2020-07-17 19:02:53 UTC
Permalink
Post by Ralf Schneider
Verbinde...
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect
(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress
(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect
(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:607)
at Newsfeed.senden(Newsfeed.java:57)
at Newsfeed.main(Newsfeed.java:42)
Verbinde...
java.net.SocketException: Socket closed .............. usw. hunderte Male.
Ja, natürlich hunderte Male. Wegen deiner while-Schleife.
Post by Ralf Schneider
Ich habe natürlich keine Ausgaben gemacht, da es unsicher ist, dass
verbunden wird.
Schreibe bitte 100 mal: "MAN FRISST NIEMALS EXCEPTIONS EINFACH AUF."

Denn das führt zu falschen Schlüssen, nämlich bei dir zu dem, dass
Thread.sleep() seinen Job nicht tut.
Post by Ralf Schneider
Es ist noch niemand da, der etwas empfangen kann. Also
würde ich gerne ein paar Sekunden warten und es dann noch einmal
versuchen.
Mal angenommen, das ergäbe Sinn: Dann müsste das Thread.sleep() *hinter*
den Try-Catch-Zauber.
Post by Ralf Schneider
Ich sehen, dass Thread.sleep(1000) nicht erreicht wird, aber ich fand
keine Methode das zu verhindern. Auch ein Timeout bewirkt keine Besserung.
Die Frage ist, was für einen Timeout du wie gesetzt hast. Mach das mal so:

Socket socket = new Socket();
int timeout = 5000;
socket.connect(isa, timeout);

Dann gibts nach 5 Sekunden eine SocketTimeoutException. Und dann das
sleep außerhalb vom Try-Catch, aber innerhalb der Schleife.

Gruß
Michael
Ralf Schneider
2020-07-17 19:53:31 UTC
Permalink
Post by Michael Paap
Post by Ralf Schneider
Verbinde...
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect
(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress
(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect
(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:607)
at Newsfeed.senden(Newsfeed.java:57)
at Newsfeed.main(Newsfeed.java:42)
Verbinde...
java.net.SocketException: Socket closed .............. usw. hunderte Male.
Ja, natürlich hunderte Male. Wegen deiner while-Schleife.
Post by Ralf Schneider
Ich habe natürlich keine Ausgaben gemacht, da es unsicher ist, dass
verbunden wird.
Schreibe bitte 100 mal: "MAN FRISST NIEMALS EXCEPTIONS EINFACH AUF."
Denn das führt zu falschen Schlüssen, nämlich bei dir zu dem, dass
Thread.sleep() seinen Job nicht tut.
Post by Ralf Schneider
Es ist noch niemand da, der etwas empfangen kann. Also würde ich gerne
ein paar Sekunden warten und es dann noch einmal versuchen.
Mal angenommen, das ergäbe Sinn: Dann müsste das Thread.sleep() *hinter*
den Try-Catch-Zauber.
Post by Ralf Schneider
Ich sehen, dass Thread.sleep(1000) nicht erreicht wird, aber ich fand
keine Methode das zu verhindern. Auch ein Timeout bewirkt keine Besserung.
Socket socket = new Socket();
int timeout = 5000; socket.connect(isa, timeout);
Dann gibts nach 5 Sekunden eine SocketTimeoutException. Und dann das
sleep außerhalb vom Try-Catch, aber innerhalb der Schleife.
Gruß Michael
Ich habe umgearbeitet:

do {
socket = new Socket();

try {
socket.connect(isa, 5000);
}
catch (ConnectException ce) {
ce.printStackTrace();
}
catch (SocketException se) {
se.printStackTrace();
}
catch (UnknownHostException uhe) {
uhe.printStackTrace();
}
catch (IOException ioe) {
ioe.printStackTrace();
}

try {
Thread.sleep(5000);
System.out.println("Verbinde...");
}
catch(InterruptedException ie) {
ie.printStackTrace();
}
}
while (!socket.isConnected());

Jetzt wird die ConnectException geworfen, die ich aber gerne ignorieren
würde. Wie gesagt, hört nicht immer jemand, worum wir uns nicht kümmern
wollen.

Verbinde...
java.net.ConnectException: Verbindungsaufbau abgelehnt (Connection
refused)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.AbstractPlainSocketImpl.doConnect
(AbstractPlainSocketImpl.java:350)
at java.net.AbstractPlainSocketImpl.connectToAddress
(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect
(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:607)
at Newsfeed.senden(Newsfeed.java:59)
at Newsfeed.main(Newsfeed.java:42)

Ich denke, damit kann ich erst einmal zufrieden sein.

Gruß
Ralf
--
http://www.kr-db.de
Michael Paap
2020-07-18 19:11:25 UTC
Permalink
Post by Ralf Schneider
Jetzt wird die ConnectException geworfen, die ich aber gerne ignorieren
würde. Wie gesagt, hört nicht immer jemand, worum wir uns nicht kümmern
wollen.
Najut. Dann würde ich sagen, ignoriere sie. Aber erst, wenn du mit
deinen Experimenten durch bist, und das Ignorieren dich nicht mehr auf
eine falsche Fährte lockt. Und schreib einen Kommentar in den
Catch-Block, warum du sie ignorierst.

Ansonsten finde ich, dass dieses ständige Versuchen, eine Verbindung
aufzubauen, eigentlich unnötig sein sollte. Wie lange willst du denn
warten? Wenn du das weißt, kannst du auch gleich den Timeout auf drei
Tage setzen und dann im Catch-Bloch nur noch ausgeben, dass du jetzt
aufgibst. :-)

Gruß
Michael
Ralf Schneider
2020-07-19 19:47:22 UTC
Permalink
Post by Michael Paap
Post by Ralf Schneider
Jetzt wird die ConnectException geworfen, die ich aber gerne ignorieren
würde. Wie gesagt, hört nicht immer jemand, worum wir uns nicht kümmern
wollen.
Najut. Dann würde ich sagen, ignoriere sie. Aber erst, wenn du mit
deinen Experimenten durch bist, und das Ignorieren dich nicht mehr auf
eine falsche Fährte lockt. Und schreib einen Kommentar in den
Catch-Block, warum du sie ignorierst.
Genau so mache ich das.
Post by Michael Paap
Ansonsten finde ich, dass dieses ständige Versuchen, eine Verbindung
aufzubauen, eigentlich unnötig sein sollte. Wie lange willst du denn
warten? Wenn du das weißt, kannst du auch gleich den Timeout auf drei
Tage setzen und dann im Catch-Bloch nur noch ausgeben, dass du jetzt
aufgibst. :-)
Das ganze ist ein Modell. Die Clients senden bis zum Umfallen und der
Server empfängt. Ich denke es gibt keinen Mechanismus dem Server eine
Sendung anzukündigen, so dass es eben so laufen muss, dass die Clients
ins Blaue hinein senden und warten. Ich fand nun, dass der Client seine
Sendung nicht los wird, wenn kein Server empfängt.

Gruß
Ralf
--
http://www.kr-db.de
Wanja Gayk
2020-07-19 20:23:23 UTC
Permalink
In article <resvjr$k3$***@gwaiyur.mb-net.net>, ***@freenet.de
says...
Post by Michael Paap
do {
socket = new Socket();
try {
socket.connect(isa, 5000);
}
catch (ConnectException ce) {
ce.printStackTrace();
}
catch (SocketException se) {
se.printStackTrace();
}
catch (UnknownHostException uhe) {
uhe.printStackTrace();
}
catch (IOException ioe) {
ioe.printStackTrace();
}
try {
Thread.sleep(5000);
System.out.println("Verbinde...");
}
catch(InterruptedException ie) {
ie.printStackTrace();
}
}
while (!socket.isConnected());
Fieses Try/Catch-Gewitter.
1. Try-with resources verwenden, denn einen Socket kann man schließen,
und sollte man auch schließen, in einem finally-Block. Das wird leider
selten richtig gemacht, darum haben sich die Designer von Java
irgendwann ein wundervolles Konstrukt ausgedacht: "Try with resources".

try (final var socket = new Socket()){

socket.connect(isa, 5000);

} catch( ....

Die Variablen sind dann auch nur innerhalb dieses Blocks sichtbar, was
grundsätzlich schön ist.

2. Catch-Blöcke kann man zusammenführen, wenn die eh alle das Gleiche
machen:

try (final var socket = new Socket()){

socket.connect(isa, 5000);

} catch( ConnectException | SocketException | UnknownHostException
| IOException ex) {
ex.printStackTrace();
}

3. Weil deine Connect-Exception eine völlig erwartete Aktion ist, willst
du sie ggf anders behandeln. Weil sie ein Untertyp von IOException ist,
musst du sie vorher fangen:

try (final var socket = new Socket()){
socket.connect(isa, 5000);
} catch (ConnectException ex){
System.out.println("will retry connection...");
} catch( SocketException | UnknownHostException
| IOException ex) {
ex.printStackTrace();
}

4. nun zum Retry und Sleep:
Wenn dein Sleep rüde unterbrochen wird, dann in der Regel, weil jemand
versucht den Thread zu beenden. Das ignoriert man nicht einfach, sondern
man sollte tun, wie einem befohlen wurde. Die Exception ist dazu da,
darauf reagieren zu könne, wenn es nötig ist. Ist es aber nicht.

Außerdem solltest du den Socket wieder verwenden, um Resourcen zu
sparen. Dazu bieten sich geschachtelte try/catches an:

try (final var socket = new Socket()){
do {
try {
socket.connect(isa, 5000);
} catch (ConnectException ex){
System.out.println("will retry connection...");
thread.sleep(5000):
}
} while (!socket.isConnected());
} catch( SocketException | UnknownHostException
| IOException | InterruptedException ex) {
ex.printStackTrace();
}

Und schon sieht der Code ein ganzes Stück kürzer und sauberer aus. Und
wenn ich nichts falsch gemacht habe, funktioniert er auch korrekter.


5. Diese Schachtellung hier mit einem Haufen Code zu füllen, der den
Socket verwendet, ist wahrscheinlich keine gute Idee, weil's schlecht
aussieht. Eine Methode sollte nicht zu viel tun. Besser man injiziert
den Code, der den Socket verwenden soll, oder man gibt den Socket
zurück. Lass mich ein Beispiel geben, wie man auszuführenden Code
injizieren kann:

void sendDataOverSocket(Socket socket){
//do something with socket
}

void sendDataToService(){
connectSocketAndDo(this::sendDataOverSocket);
}

void connectSocketAndDo(Consumer<Socket> job){
try (final var socket = new Socket()){
do {
try {
socket.connect(isa, 5000);
job.accept(socket);
} catch (ConnectException ex){
System.out.println("will retry connection...");
thread.sleep(5000):
}
} while (!socket.isConnected());
} catch( SocketException | UnknownHostException
| IOException | InterruptedException ex) {
ex.printStackTrace();
}
}

6. (Hausaufgabe) Es ist selten gut, wenn der Service ewig probiert, ggf.
wäre es sinvoll ein Limit für Retries zu setzen.


Gruß,
-Wanja-
--
..Alesi's problem was that the back of the car was jumping up and down
dangerously - and I can assure you from having been teammate to
Jean Alesi and knowing what kind of cars that he can pull up with,
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]
Ralf Schneider
2020-07-19 22:41:20 UTC
Permalink
Post by Wanja Gayk
6. (Hausaufgabe) Es ist selten gut, wenn der Service ewig probiert, ggf.
wäre es sinvoll ein Limit für Retries zu setzen.
Gruß,
-Wanja-
Vielen Dank für diese vielen Zeilen Code. Einiges ist mir noch unbekannt.
Den Socket möchte ich möglichst spät schließen und die Verbindung für das
Dauerfeuer an kurzen Informationen offen halten.

Gruß
Ralf
--
http://www.kr-db.de
Claus Reibenstein
2020-07-31 19:58:35 UTC
Permalink
Post by Michael Paap
Post by Ralf Schneider
while (socket.isConnected() == false) {
while(! socket.isConnected() {
Aber leider syntaktisch falsch ;-)

Gruß
Claus
Claus Reibenstein
2020-07-31 19:57:42 UTC
Permalink
Post by Ralf Schneider
while (socket.isConnected() == false) {
¯¯¯¯¯¯¯¯

Bei solchen Konstruktionen packt mich immer das Grausen :-(

Profis schreiben da so:

while (!socket.isConnected()) {

Gruß
Claus
Ralf Schneider
2020-08-03 18:47:14 UTC
Permalink
Post by Claus Reibenstein
Post by Ralf Schneider
while (socket.isConnected() == false) {
¯¯¯¯¯¯¯¯
Bei solchen Konstruktionen packt mich immer das Grausen :-(
while (!socket.isConnected()) {
Gruß Claus
Ich will das ganze verständlich und lesbar erstellen. Das ist Neuland für
mich. Der Rückgabewert ist doch der gleiche oder nicht ?

Gruß
Ralf
--
http://www.kr-db.de
Michael Paap
2020-08-03 21:14:05 UTC
Permalink
Post by Ralf Schneider
Ich will das ganze verständlich und lesbar erstellen. Das ist Neuland
für mich. Der Rückgabewert ist doch der gleiche oder nicht ?
Ja, ist er. Aber:

socket.isConnected() ist ein Ausdruck vom Typ boolean, wertet also zu
true oder false aus. Und das vergleichst du dann mit false. Dein Konstrukt

socket.isConnected() == false

ist wiederum ein Ausdruck vom Typ boolean. Konsequenterweise müsstest du
den nun wieder mit true oder false vergleichen. Und so weiter.

Oder du erkennst, dass das eine nie endender Unfug wäre und verwendest
einfach direkt den ersten booleschen Ausdruck. Und da du willst, dass
Konstrukt zu dessen Verneinung auswertet, verneinst du ihn eben und hast
dann

!socket.isConnected()

Boolesche Ausdrücke mit true oder false zu vergleichen ist Unfug. Sie
*sind* bereits true oder false. Du schreibst ja hoffentlich auch nicht
sowas wie

if(ergebnis == 42 != true) { ... }

Gruß
Michael
Patrick Roemer
2020-08-03 21:38:34 UTC
Permalink
Post by Michael Paap
Dein Konstrukt
socket.isConnected() == false
ist wiederum ein Ausdruck vom Typ boolean. Konsequenterweise müsstest du
den nun wieder mit true oder false vergleichen. Und so weiter.
Oder du erkennst, dass das eine nie endender Unfug wäre und verwendest
einfach direkt den ersten booleschen Ausdruck.
Die Argumentation träfe auf "socket.isConnected() == true" zu. In diesem
Fall braucht man aber eben noch einen weiteren Berechnungsschritt...
Post by Michael Paap
Und da du willst, dass
Konstrukt zu dessen Verneinung auswertet, verneinst du ihn eben und hast
dann
!socket.isConnected()
...und da muss man halt begründen, warum Negation diesen besser
ausdrückt als ein Vergleich mit false. Der Verweis auf die unendliche
Regression greift hier IMHO nicht wirklich.

Viele Grüße
Patrick
Michael Paap
2020-08-04 07:19:40 UTC
Permalink
Post by Patrick Roemer
Post by Michael Paap
Dein Konstrukt
socket.isConnected() == false
ist wiederum ein Ausdruck vom Typ boolean. Konsequenterweise müsstest du
den nun wieder mit true oder false vergleichen. Und so weiter.
Oder du erkennst, dass das eine nie endender Unfug wäre und verwendest
einfach direkt den ersten booleschen Ausdruck.
Die Argumentation träfe auf "socket.isConnected() == true" zu. In diesem
Fall braucht man aber eben noch einen weiteren Berechnungsschritt...
Post by Michael Paap
Und da du willst, dass
Konstrukt zu dessen Verneinung auswertet, verneinst du ihn eben und hast
dann
!socket.isConnected()
...und da muss man halt begründen, warum Negation diesen besser
ausdrückt als ein Vergleich mit false. Der Verweis auf die unendliche
Regression greift hier IMHO nicht wirklich.
Ich sag mal aus langjähriger Erfahrung mit einigen zehntausend
Java-Neulingen: Die Mehrheit derer, die

socket.isConnected() == false

statt

!socket.isConnected()

schreibt, vergleicht auch, wenn keine Verneinung im Spiel ist, mit true
und false, schreibt also ggf. auch

if (socket.isConnected() == true) { ... }

Sowas sehe ich ständig. Dem liegt ein Mangel an Verständnis dessen
zugrunde, was ein Ausdruck ist. Kann man beheben. :-)

Gruß
Michael
Wanja Gayk
2020-12-18 00:25:33 UTC
Permalink
Post by Michael Paap
Ich sag mal aus langjähriger Erfahrung mit einigen zehntausend
Java-Neulingen: Die Mehrheit derer, die
socket.isConnected() == false
statt
!socket.isConnected()
schreibt, vergleicht auch, wenn keine Verneinung im Spiel ist, mit true
und false, schreibt also ggf. auch
if (socket.isConnected() == true) { ... }
Stimmt, aber ich halte es in der Pauschalität falsch das zu ächten.

1. Sowas optimiert jeder billige Compiler weg.
2. Lesbarkeit ist Trumpf. Ein ! Ist oft einfach zu übersehen, manchmal
ist der schlichte Vergleich mit false einfach sehr viel deutlicher.

wenn ich eine Reihe von Vergleichen habe, wie:

optionA.setEnabled(lineA1() == true && lineB2() == true);
optionB.setEnabled(lineC2() == false && lineB1() == true);

Dann sind all die "true" und "false" zwar überflüssig, aber:
es kann sich sehr schön mit einer Tabelle aus einer Spezifikation decken
und in so einer Situation ist es ggf. durchaus wert so geschrieben zu
werden, sprich: Es ist nicht pauschal falsch bewusst auf die kleinen,
unauffälligen "!" zu verzichten und stattdessen mit einem boolean zu
vergleichen.

Extrem unglücklichen Beispiel:
optionC.setEnabled(lineC2() && lineB1());
optionD.setEnabled(!inEC1() && !inEC2());

Joel Spolsky, streitbar, wie seine Meinungen sind, schrieb einmal in
einem Artikel, man sollte darauf achten, Code so zu schreiben, dass
Sachen, die falsch sind, auch falsch aussehen.

Sowas, wie
entity.setWhat(taintedWhatever()); // sollte einen Alarm im Kopf läuten
entity.setWhat(validatedWhatever()); // sieht richtig aus
statt:
entity.setWhat(whatever()); // wurde das valdiiert oder nicht?

Da denke ich selbst viel zu selten dran, aber hat was.
In dem Fall oben kann sowas eben auch auftreten.

Oder kurz:
Nen Computer kann man auch in Whitespace oder Malboge programmieren,
solange die Runtime den Code versteht, ist dem Recher egal, wie scheiße
der Code zu lesen ist. Daher ergibt sich:
Code ist nicht dafür da dem Rechner zu gefallen, sondern den Autoren.

Gruß,
-Wanja-
--
..Alesi's problem was that the back of the car was jumping up and down
dangerously - and I can assure you from having been teammate to
Jean Alesi and knowing what kind of cars that he can pull up with,
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]
Michael Paap
2020-12-18 06:55:59 UTC
Permalink
Am 18.12.2020 um 01:25 schrieb Wanja Gayk:

[Zeug]

Ich bin es aus Gründen gerade unendlich leid, Diskussionen zu führen, in
denen jemand mit absurden Beispielen gegen Aussagen argumentiert, die
Post by Wanja Gayk
1. Sowas optimiert jeder billige Compiler weg.
Ach. Echt jetzt?
Post by Wanja Gayk
Code ist nicht dafür da dem Rechner zu gefallen
Ach. Echt jetzt?
Post by Wanja Gayk
sondern den Autoren.
Jo, ich kenne auch Romanautoren, die so schreiben. Beruf verfehlt.

Aber passt ja. Deine Codebeispiele da oben... das ist genau das typische
Zeug, das sich /nicht/ an den verständigen Leser richtet, sondern an den
Autor selbst.

Gruß
Michael
Wanja Gayk
2020-12-18 12:26:07 UTC
Permalink
Post by Michael Paap
Ich bin es aus Gründen gerade unendlich leid, Diskussionen zu führen, in
denen jemand mit absurden Beispielen gegen Aussagen argumentiert, die
Das war schon auf den Punkt, aber egal.

[Wertlose, abfällige Reaktion gelöscht]

Heute zu hart geschissen?

Gruß,
-Wanja-
--
..Alesi's problem was that the back of the car was jumping up and down
dangerously - and I can assure you from having been teammate to
Jean Alesi and knowing what kind of cars that he can pull up with,
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]
Patrick Roemer
2020-12-18 15:41:35 UTC
Permalink
Post by Wanja Gayk
2. Lesbarkeit ist Trumpf. Ein ! Ist oft einfach zu übersehen, manchmal
ist der schlichte Vergleich mit false einfach sehr viel deutlicher.
Wenn das tatsächlich ein Problem wäre, liefe das doch eigentlich darauf
hinaus, dass die API für boolesche Algebra an sich schlecht lesbar ist.
Die Lösung sollte dann eher sein, die API zu verbessern (bzw. eine
eigene Variante draufzusetzen, also z.B. ein #not()-Alias für "!") und
nicht, sie zu vermeiden...?
Post by Wanja Gayk
optionA.setEnabled(lineA1() == true && lineB2() == true);
optionB.setEnabled(lineC2() == false && lineB1() == true);
es kann sich sehr schön mit einer Tabelle aus einer Spezifikation decken
Ich würde dann lieber "||" statt "&&" verwenden, um den
Tabellencharakter zu betonen. ;)

Ich mag den Gedanken, den Code möglichst nah an der Domänenspezifikation
zu halten. Wenn das aber einen Konflikt mit den Sprachkonventionen gibt,
würde ich letzteren den Vorzug geben. (Das betrifft auch das unübliche
Alignment.)

Ist natürlich schlußendlich alles Geschmackssache und mag in einem
bestimmten Projekt/Team akzeptabel sein. Das wäre dann schon ein
spezialgelagerter Sonderfall, der eher schlecht generalisierbar ist,
schon gar nicht auf den Codeschnipsel, auf den sich dieser Teilthread
bezieht.
Post by Wanja Gayk
optionC.setEnabled(lineC2() && lineB1());
optionD.setEnabled(!inEC1() && !inEC2());
Finde ich jetzt auch nicht so dramatisch. Color coding von Operatoren in
der IDE hilft auch. :) Und, s.o., wenn das ein Problem wäre, sollte man
die API verbessern.
Post by Wanja Gayk
entity.setWhat(taintedWhatever()); // sollte einen Alarm im Kopf läuten
entity.setWhat(validatedWhatever()); // sieht richtig aus
entity.setWhat(whatever()); // wurde das valdiiert oder nicht?
Andere Baustelle - das schaut nach etwas aus, was man idealerweise im
Typsystem lösen will. Wenn "tainted whatever" und "validated whatever"
unterschiedliche Typen sind, sehen Sachen, die falsch sind, nicht nur so
aus, sondern sind es auch schon für den Compiler.

Viele Grüße
Patrick

Patrick Roemer
2020-08-03 21:33:42 UTC
Permalink
Post by Ralf Schneider
Post by Claus Reibenstein
Post by Ralf Schneider
while (socket.isConnected() == false) {
¯¯¯¯¯¯¯¯
Bei solchen Konstruktionen packt mich immer das Grausen :-(
while (!socket.isConnected()) {
Ich will das ganze verständlich und lesbar erstellen. Das ist Neuland für
mich. Der Rückgabewert ist doch der gleiche oder nicht ?
Ja. Aber vergleiche einfach mal die natürlichsprachigen Varianten:

"Solange es falsch ist, dass die Verbindung besteht..."

und

"Solange die Verbindung nicht besteht..."

Was wirkt da verständlicher und lesbarer?

Etwas abstrakter könnte man argumentieren, dass Deine Version die
Intention des Codes weniger präzise ausdrückt: Man will eigentlich nicht
den Wert, den man hat, mit einem vorgegebenen Zielwert vergleichen, um
so zu einem Wahrheitswert zu gelangen, sondern man hat bereits einen
Wahrheitswert und will diesen negieren.

Viele Grüße
Patrick
Claus Reibenstein
2020-08-04 19:18:57 UTC
Permalink
Post by Ralf Schneider
Post by Claus Reibenstein
Post by Ralf Schneider
while (socket.isConnected() == false) {
¯¯¯¯¯¯¯¯
Bei solchen Konstruktionen packt mich immer das Grausen :-(
while (!socket.isConnected()) {
Ich will das ganze verständlich und lesbar erstellen.
Eben. Genau deshalb.
Post by Ralf Schneider
Der Rückgabewert ist doch der gleiche oder nicht ?
Ja, ist er. Darum geht's aber nicht.

Du vergleichst einen boole'schen Wert mit einem boole'schen Wert und
erhältst einen boole'schen Wert, den Du dann auswertest, anstatt den
ersten boole'schen Wert direkt auszuwerten. Das ist unsinnig.

Und was die Verständlichkeit und Lesbarkeit angeht:
!socket.isConnected() empfinde ich als verständlicher und lesbarer als
socket.isConnected() == false.

Gruß
Claus
Ralf Schneider
2020-08-05 09:04:49 UTC
Permalink
Post by Claus Reibenstein
Post by Claus Reibenstein
Post by Ralf Schneider
while (socket.isConnected() == false) {
¯¯¯¯¯¯¯¯
Bei solchen Konstruktionen packt mich immer das Grausen :-(
Du vergleichst einen boole'schen Wert mit einem boole'schen Wert und
erhältst einen boole'schen Wert, den Du dann auswertest, anstatt den
ersten boole'schen Wert direkt auszuwerten. Das ist unsinnig.
Das ist verständlich. Es geht um Laufzeitoptimierung. Ich denke nicht so
viel nach, was die VM zu arbeiten hat. Das muss ich mir angewöhnen.

Gruß
Ralf
Michael Paap
2020-08-05 09:44:29 UTC
Permalink
Post by Ralf Schneider
Das ist verständlich. Es geht um Laufzeitoptimierung. Ich denke nicht so
viel nach, was die VM zu arbeiten hat. Das muss ich mir angewöhnen.
Ich wage mal, zu behaupten, dass es weder Claus noch Patrick um
Laufzeitoptimierung geht. Mir geht es darum jedenfalls ganz ganz sicher
nicht.

Im konkreten Fall wird es da mit hoher Sicherheit auch absolut keinen
Unterschied geben, weil der Compiler die unsinnigen Konstrukte eh'
eindampfen dürfte.

Es geht um Lesbarkeit und darum, dass ein boolescher Ausdruck ein
boolescher Ausdruck ist.

Gruß
Michael
Lesen Sie weiter auf narkive:
Suchergebnisse für 'Thread.sleep() hält den Thread nicht an' (Fragen und Antworten)
5
Antworten
Wieso 4.0 und nicht 3.1?
gestartet 2016-12-18 18:34:20 UTC
behinderte
Loading...