Am 04.09.19 um 16:45 schrieb Heiko Schlittermann:
Manchmal denke ich mir, dass vieles deutlich einfacher wäre, wenn es nur stdout
geben würde,
und nicht noch stderr. Diese zwei Ströme machen es manchmal nervig.
Du meinst das nicht ernst, oder :)
Doch, ich meine das Ernst. Continuous Integration hat mich geformt und das ist
gut so.
Entweder alle Tests sind ok, oder ein oder mehrere Tests sind nicht ok. Das ist
binär,
da gibt es kein "vielleicht, naja, mal sehen".
Genau diese zwei Ströme sind genial. Woher kannst Du sonst
Betriebsdaten von Fehlermeldungen unterscheiden?
Es ist für mich binär: Es war erfolgreich (keine Warnungen) oder es war nicht
erfolgreich,
dann gibt es (neben der Fehlermeldung) keinen Output (du nennst es
Betriebsdaten).
http hat sich durchgesetzt. Da gibt es klare return-codes. Wenn man eine 200
bekommt, dann passt
es und ich kann die Nutzdaten verarbeiten. Wenn ich zB eine 404 bekomme, dann weiß ich, dass in den Daten nur eine
Fehlermeldung steht, also keine Betriebs/Nutzdaten.
Das ist etwa wie "Shell vs Programmiersprache". Bei der Shell gibt es eine
Warnung auf stderr
und dann wird lustig die nächste Zeile ausgewertet. Da werde ich zum Autist. So
kann
ich keine zuverlässigen Produkte erstellen. Die Shell wird bei mir nur noch
interaktiv verwendet.
Wichtiger sind aber automatisierte Tests. Wenn es davon genug gibt, dann ist es
eigentlich egal
wie die Implementierung arbeitet.
</etc/hosts grep -P '*' | wc -l # eigener Datenstrom für die Fehler
vs
</etc/hosts grep -P '*' |& wc -l # alles zusammen
Ich bin kein Nachrichtentechniker, geschweige denn Informatiker, aber
in-band und out-of-band signallig kommen mir da in den Sinn. Ob das hier
paßt, weiß ich nicht. Aber die Ausgabeströme zu verwursten kommt mir
sehr falsch vor. Denn dadurch verlierst Du Information, die Du später
gut brauchen könntest.
Andere non-shell Beispiele:
# C
errno = 0; // to be safe
int d = get_delta(); // how to declare failure?
if (errno) perror("delta")
# Perl
$d = get_delta(); # return undef on failure, details in $@
if (not defined $d) {
die $@
};
# Go
d, err := get_delta() // return err != nil on error
if err != nil {
fmt.Fatal(err)
}
Du schlägst gerade etwas vor, was dem von „C“ entspricht. (Nicht falsch
verstehen, ich finde „C“ eine super Sprache, sollte jeder lernen, der
was mit Programmieren tut.)
In meinem Kontext werden bei Fehlern in der Regel Exceptions geworfen.
Gruß,
Thomas
--
Thomas Guettler http://www.thomas-guettler.de/
I am looking for feedback: https://github.com/guettli/programming-guidelines
