Ich entwickle ein großes Projekt in C mit anderen Teammitgliedern, und wir haben Unstimmigkeiten darüber, wie "das kann nie passieren" -Stil von Fehlern behandelt werden. Damit meine ich Fehlerfälle, die der Code derzeit niemals erreichen kann, aber jemand kann den Code ändern und nach der Änderung ist es möglich, dass der Fehlerfall erreicht wird.
Nehmen wir zum Beispiel an, ich habe eine Funktion, die entweder 0 bei Erfolg oder -EINVAL zurückgibt, wenn ihr ein NULL-Argument gegeben wird. Was ich natürlich mache ist:
%Vor%oder sogar:
%Vor%... um zwischen den beiden Fällen von -EINVAL und unbekanntem Fehlercode zu unterscheiden.
Die Vorteile dieses Ansatzes zur Fehlerbehandlung bestehen darin, dass es einfach zu programmieren ist (wenige Codezeilen) und hinterlässt eine Kerndatei, die verwendet werden kann, um die Situation schnell zu debuggen.
Einige Teammitglieder sind jedoch mit dieser Fehlerbehandlung nicht einverstanden, da ich einen unsauberen Exit mache und der Code derzeit niemals die abort () Zeile erreichen kann, ist es möglich, dass jemand in der Zukunft den Code ändert und es erreicht abort () Zeile dann. Laut ihnen sollte ich versuchen, einen kontrollierten Ausgang zu machen und den Grund dem Benutzer auszudrucken. Also, ich denke, statt dessen sollte ich tun:
%Vor%Meiner Meinung nach ist diese zweite Fehlerbehandlungsstrategie schlechter, weil sie keine Kerndatei zurücklässt, die zum Debuggen dieser Situation verwendet werden kann. Darüber hinaus führt dies zu Code, der mehr Codezeilen enthält.
Also, die Frage ist, wie sollte "das kann nie passieren" Stil der Fehler in C behandelt werden? Soll ich einen Abbruch oder einen kontrollierten Exit mit einer beschreibenden Fehlermeldung durchführen?
Grundsätzlich sollten Sie immer mit Fehlern umgehen und möglichst erklärende Beschreibungen für den Benutzer generieren. Das ist das Richtige, was man in Japan honte nennen würde.
In der Praxis ist jedoch Ihr unerklärtes abort() im ersten Beispiel das, was die meisten tun, weil es schneller zu schreiben ist. Die Folge davon ist, dass die meisten Anwendungen, wenn sie scheitern, kläglich austreten. Wenn beispielsweise Microsoft Word abstürzt, lautet die Meldung an den Benutzer: "Word hat ein Problem festgestellt und wird jetzt beendet." oder etwas in diesem Sinne. Viele Anwendungen geben überhaupt keine Nachricht, sondern enden einfach.
Die richtige Programmierung besteht darin, den sogenannten negativen Pfad vollständig zu codieren. Nicht nur sollte jeder mögliche Fehler eine sinnvolle Textnachricht erzeugen, sondern auch, wenn der Fehler zurückkehrt und rückwärts durch die Anrufkette läuft, sollte jede aufrufende Funktion ihren Kontext und alle relevanten Parameter an der Vorderseite der Nachricht hinzufügen. Die Endnachricht für den Benutzer sollte also etwa so lauten:
Beim Versuch, zu initialisieren: beim Versuch, die Konfiguration zu laden Datei unter [c: \ user \ data \ configuration.ini]: Zeile 453 konnte nicht gelesen werden: ungültiger Parameterwert 'NumRedirects' (außerhalb der Grenzen): -43
In dieser Fehlermeldung sehen wir, dass jede Funktion, wie sie den Fehler empfängt, ihren Kontext am Anfang einer Zeichenfolge gefolgt von einem Doppelpunkt einfügt und dann den Fehler an die Funktion zurückgibt, die sie aufgerufen hat. Das Nettoergebnis zeigt alle wichtigen Informationen an (die Datei, die gelesen wurde, die Zeile, die analysiert wurde, der Parameter, der geladen wurde, der ungültige Wert, der für den Parameter angegeben wurde). Dieses erklärt dem Benutzer (oder Entwickler) vollständig, was das Problem war.
Ich denke, dafür sind Behauptungen. Der Rückgabewert wird überprüft, es sei denn, der Code wird mit NDEBUG definiert.
Die Idee ist, dass Fehler normalerweise zu unerwarteten führen. Auch erhöhen Behauptungen die Lesbarkeit des Codes. Wenn die Assertion fehlschlägt, hilft die automatische Fehlermeldung dem Programmierer, die fehlgeschlagene Assertion zu identifizieren. Die Release-Version kann mit -DNDEBUG erstellt werden, um die Anzahl der Zweige zu reduzieren.
Tags und Links c error-handling core