Fangcodes in Produktionsumgebungen erfassen?

Question

Ich möchte wissen, ob für alle Funktionen, die wir für die Produktionsumgebung schreiben Rückkehrcodes überprüfen. für e, g, ich benutze C viel und Sie fangen die Rückkehr-Codes für die Standard-Bibliothek auch, nicht nur die Funktionen, die Sie schreiben, sondern die 3rd Party API/Standard-Bibliothek/andere Bibliothek.

Die meisten Code, den ich in der Produktion sehe, tun dies nicht. Also meine Frage ist an die erfahrenen Leute, die in Produktionsumgebungen gearbeitet haben und Produktionscode für etwa 20 Jahre oder so geschrieben haben. Fangen Sie den Rückgabecode von der API/Standardbibliothek/anderen Bibliothek von Drittanbietern und nicht nur von den Funktionen, die Sie implementieren? nur um ein Beispiel zu geben, was ich meine sagen Sie fangen Rückkehrcodes für die C-Standard-Lib-Funktionen (snprintf/sprintf, strncat/strcat und so weiter .., ..) C-Standard-Bibliothek.

Vielen Dank für Ihre Antworten.

Answer 1

Ich glaube nicht, dass Sie eine Alles-oder-nichts-Ansatz dazu nehmen sollten. Capture Rückkehr/Fehlercodes, wenn Sie erwarten Probleme mit dem Funktionsaufruf (oder natürlich, wenn Ihre nachfolgende Berechnung hängt davon ab, was die Funktion zurückgibt). Wenn Sie jedoch ziemlich sicher sind, dass der Aufruf nicht zu Fehlern führen kann (oder Sie den Rückgabewert auch nicht anderweitig verwenden), überspringt do das Erfassen des Rückgabewerts.

Dies ist einer dieser Bereiche, in denen man sich auf das technische Urteil eines Individuums verlassen kann, nicht auf einige vorgeschriebene "Best Practices". Auch das gleiche Denken würde meiner Meinung nach für die Ausnahmebehandlung gelten.

Answer 2

snprintf ist nützlich, da Sie einen größeren Puffer dann versuchen Sie es erneut zuweisen möchten, oder Sie können es in einer Abfolge anrufen:

// cons lists as [a,b,c, ...] 
if (type == kin_cons_class()) { 
    size_t offs = snprintf (buf, max, "["); 

    if (offs >= max) 
     return nul_terminate (buf, offs, max); 

    size_t count = depth; 

    kin_cons_ref_t empty = kin_cons_nil(); 
    kin_cons_ref_t cons; 

    for (cons = ref; cons != empty; cons = kin_cons_tail (cons)) { 
     if (count > 15) { 
      offs += snprintf (buf + offs, max - offs, ", ..."); 

      break; 
     } 

     if (cons != ref) { 
      offs += snprintf (buf + offs, max - offs, ","); 

      if (offs >= max) 
       return nul_terminate (buf, offs, max); 
     } 

     offs += string_repr (buf + offs, max - offs, kin_cons_head (cons), depth, escape_strings); 

     if (offs >= max) 
      return nul_terminate (buf, offs, max); 

     ++count; 
    } 

    if (offs >= max) 
     return nul_terminate (buf, offs, max); 

    offs += snprintf (buf + offs, max - offs, "]"); 

    return nul_terminate (buf, offs, max); 
} 

Wenn Sie ohne alle offs >= max Tests in Gang halten, erhalten Sie eine Pufferüberlauf und es wird segfault.

Das passiert nicht mit printf, daher ist es weniger üblich, die Rückgabe zu überprüfen.

Wenn Sie Ihr Verhalten ändern müssen, je nachdem, ob eine Funktion gearbeitet, überprüfen Sie die Rückkehr. Viele Standardbibliotheksfunktionen können entweder fehlschlagen oder später zu undefiniertem Verhalten führen, daher müssen Sie diese Rückgaben überprüfen.

Wenn Sie das Verhalten nicht basierend auf dem Rückgabewert ändern müssen, ist es nicht sinnvoll, es zu überprüfen.

Answer 3

Wenn die Funktion Fehlercode zurückgeben kann - überprüfen Sie es immer und damit umgehen, wie dies einfach. Diese Regel kann Ihnen bei der Fehlersuche viel Zeit sparen.

Wenn Funktion immer den Code zurückgibt, der den Fehler nicht anzeigen kann und Sie das Ergebnis nicht benötigen (wie printf) natürlich können Sie es ignorieren.

Answer 4

Es dauerte eine lange Zeit, um dies zu lernen, aber abgesehen von wenigen Ausnahmen sollten Sie immer überprüfen Sie den Rückkehrcode einer Funktion.

Ich habe viel zu viel Code gesehen, dass malloc (zum Beispiel) ruft und benutzt nur glücklich den Zeiger er zurückkehrt. 99,9% der Zeit ist dies kein Problem, aber gelegentlich malloc wird fehlschlagen und Ihr Programm wird abstürzen, wenn Sie versuchen, einen Nullzeiger dereferenzieren.Nun könnte man argumentieren, dass Sie beenden möchten, wenn malloc trotzdem NULL zurückgibt - und das mag wahr sein, aber Sie sollten immer danach streben, selbst bei einem fatalen Fehler elegant zu beenden.

Also, ja: Überprüfen Sie die Rückkehrcodes. Gehen Sie nicht davon aus, dass etwas funktioniert, nur weil es in der Vergangenheit immer funktioniert hat. Dinge scheitern die ganze Zeit. Sie sparen sich viel Zeit und Leid, indem Sie defensiv codieren, auf Fehler prüfen, errno überprüfen, strerror ausgeben und fehlerfrei versagen.

Answer 5

Wenn die Funktion einen Fehlercode zurückgibt, sollte Ihr Anrufcode entscheiden, wie ein Fehler behandelt wird. Bei einigen Programmen kann das Ignorieren des Fehlers OK sein; Dies ist in der Regel das, was Leute mit Fehlern aus der Standard-I/O-Bibliothek tun, wenn sie beispielsweise in stderr schreiben. (Was können Sie tun, wenn die Nachricht fehlgeschlagen ist? Beenden? Machst du das überhaupt?)

Eine Quelle von Ärgernis sind Funktionen, die dokumentiert werden, um einen Wert zurückzugeben, aber immer den gleichen Wert zurückgeben (normalerweise 0). Oft sind dies Funktionen, die ursprünglich in K & R C geschrieben wurden, bevor es eine void Rückgabe gab. Sie wurden in int konvertiert und dann wurde eine 'return(0);' hinzugefügt, um Warnungen zu "Funktion gibt keinen Wert zurück" zu quellen, anstatt sie in void umzuwandeln, wie es hätte sein sollen. Solche Funktionen sollten überarbeitet werden auf void; In der Zwischenzeit ist es in Ordnung, den Fehlerrückgabewert zu ignorieren.

Ich stimme nicht mit der Beobachtung in einer anderen Antwort "Capture Return/Fehlercodes, wenn Sie Probleme mit dem Funktionsaufruf erwarten". Das Problem ist genau das Unerwartete, was dich umbringt. Selbst die stabilsten Operationen können unerwartet fehlschlagen (vielleicht ist das DBMS abgestürzt, also obwohl Sie eine Verbindung hatten, Sie nicht mehr), und Ihre Software muss solche Probleme erkennen und behandeln.

Answer 6

Ja, mit sehr wenigen Ausnahmen sollte Ihr Programm immer nach Fehlerrückgabewerten suchen und diese verarbeiten, auch (insbesondere) wenn Sie keine Fehler erwarten. Die Umgebung unserer Software ist oft weniger zuverlässig als wir es uns wünschen.

Aus diesem Grund haben die meisten modernen Sprachen Ausnahmen: unter anderem bieten sie einen "Standardfehlerhandler" (Abbruch und Stapelverfolgung) für Fehler, die Sie nicht explizit behandeln (d. H. Fangen). Sie ermöglichen auch die Zentralisierung der Fehlerbehandlung, anstatt den Rückgabewert jedes Funktionsaufrufs zu überprüfen.