Thomas Güttler <guettl...@thomas-guettler.de> (Do 05 Sep 2019 13:01:36 CEST): > 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 verstehe ich jetzt nicht. Command Line Applications haben eine klare
Konvention, was Return Codes angeht. Und es liegt an Dir, Daten, die auf
STDOUT erscheinen, zu ignorieren und Daten auf STDERR dann als
beschreibende Details zum Fehler zu verstehen.
Und es ist gut, daß diese Dinge nicht jeder selbst implementieren muss,
sondern daß genau dafür die Shell da ist, die unerwünschte und nicht
unterdrückbare Betriebsausgaben nach /dev/null schickt.
Also ich verstehe das Problem noch nicht. Die Unix-Idee mit der Shell
gibt mir die Flexibilität und schränkt mich nicht ein.
> 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
Shell *ist* Programmiersprache.
Was Du mit nächste Zeile meinst, weiß ich jetzt nicht, ob im Script oder
bei der Verarbeitung der Daten. Die Shell¹ kennt „set -e“. Sehr nützlich.
> 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.
Ob zuverlässig oder nicht, hängt sicher von der Aufgabenstellung ab. Ich
denke, für Dein Eingangsproblem ist die Shell zuverlässig genug :)
Und ich erkenne nicht, wie diese zwei Ausgabekanäle Deine automatisierte
Auswertung erschweren - im Gegenteil, sie wird vereinfacht, weil Du eben
Betriebsdaten (die Du vielleicht nicht unterdrücken kannst) von anderen
Daten trennt.
> > # 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.
Das „die()“ im Perl Beispiel kann wie eine Exception behandelt werden.
In Go könnte man statt fmt.Fatal() mit panic() arbeiten, aber man hat da
eine etwas andere Einstellung zu Fehlern. Nur die wirklichen „this
should not happen“ sollten eine Panic erzeugen, andere sollten als
diskreter Fehler an den Aufrufer zurückgeliefert werden. Aber das ist
eine andere Baustelle als Dein Eingangsproblem, denke ich.
--
Heiko
signature.asc
Description: PGP signature
