Ist die Funktionsparameterüberprüfung mit Fehlern ein gutes Muster in Go?

Question

Wird die Parametervalidierung mit Fehlerrückkehrcodes als gute Praxis angesehen? Ich meine, wo sollte jemand Fehler gegen Paniken verwenden (gibt es irgendwelche Richtlinien?).

Zum Beispiel:

• prüfen für Nicht-Null + Rückkehr eines Fehlers, wenn es Null eine gute Praxis ist?
• Oder für die korrekte ganze Zahl Überprüfung Bereiche usw.

Ich stelle mir vor, dass Fehler verwenden, die oft würde sehr C-ish fühlen und würde ziemlich schlecht aussehen. Sind Paniken in diesen Situationen eine gute Alternative?

Oder sollte ein Gopher den Python/Ruby/JS-Ansatz "nur lassen es scheitern"?

Ich bin ein bisschen verwirrt, weil Panik für echte "Fehler" in meinem Verständnis sind. Aber mit Fehlern die ganze Zeit ist nur schlecht.

Und selbst wenn ich Fehlercode zurückgeben würde: Was könnte ich tun, wenn jemand falsche Parameter an meine Funktion übergibt, aber die Fehlercodes ignoriert? -> Nichts! Also ehrlich gesagt würde ich sagen, Paniken sind für diese Situationen gut, aber in einer Sprache, in der Fehlercodes über Panik verwendet werden, ist dies nicht sehr klar.

Answer 1

„Escaping“ panic s in Go (ich meine, solche, die durch die Funktionen erzeugt werden könnten, die öffentliche API Ihres Pakets umfasst) sind mit Fehlern umgehen Programmierer tun. Also, wenn Ihre Funktion bekommt einen Zeiger auf ein Objekt, und das kann nicht nil (sagen wir, um anzuzeigen, dass der Wert fehlt) gehen Sie einfach und dereferenzieren Sie den Zeiger, um die Laufzeit panic selbst, wenn es passiert, nil sein. Wenn eine Funktion eine Ganzzahl erwartet, die in einem bestimmten Bereich liegen muss, panic, wenn sie nicht in diesem Bereich liegt — weil in einem korrekt Programm alle Werte, die an Ihre Funktion übergeben werden können, sind in diesem Bereich, und wenn sie nicht ' t dann hat entweder der Programmierer die API nicht befolgt, oder sie haben den von außen erhaltenen Wert nicht bereinigt, was wiederum nicht Ihre Schuld ist.

Auf der anderen Seite wird öffnen Probleme wie Ausfall eine Datei oder einen pefrorm eine andere Aktion Ihrer Funktion soll auszuführen, wenn richtig sollen aufgerufen nicht Ursache panic s und die Funktion sollten stattdessen einen entsprechenden Fehler zurück.

Beachten Sie, dass die Empfehlung zur expliziten Überprüfung auf null Parameter in den Funktionen von öffentlichen APIs in .NET und Java-Code ein anderes Ziel hat, solche Arten von Fehlern lesbarer zu machen. Aber da 99% des .NET- und Java-Codes alle Exceptions auf die oberste Ebene propagieren (und dann angezeigt oder protokolliert werden), ersetzt sie nur eine (durch die Laufzeit generierte) Exception durch eine andere. Es macht möglicherweise Fehler offensichtlicher — die Ausführung schlägt in der API-Funktion, nicht irgendwo tiefer in den Call-Stack —, aber fügt unnötigen cruft zu diesen API-Funktionen. Also ja, das ist eigensinnig aber meine subjektive Meinung ist: es einfach stürzen zu lassen ist OK in Go — du bekommst einen beschreibenden Stack Trace.

TL; DR

Im Hinblick auf die Verarbeitung von Laufzeitprobleme,

• panic s für Programmierfehler sind;
• Rückgabe Fehler ist für Probleme mit der Durchführung der vorgesehenen Aufgaben von Funktionen.

---

Eine andere legitime Verwendung für panic s ist schnell "Kalt Weg" aus der Tiefe rekursive Verarbeitung/Berechnung der Rückkehr; In diesem Fall sollte panic von Ihrem Paket abgefangen und verarbeitet werden, und die entsprechenden öffentlichen API-Funktionen sollten Fehler zurückgeben. Weitere Informationen finden Sie unter this und this.

Answer 2

Die Antwort darauf ist subjektiv. Hier sind meine Gedanken:

Panik In Bezug auf, wie ich dieses Zitat von Go By Example (ref)

Eine Panik normalerweise bedeutet, etwas ging unerwartet falsch. Meistens verwenden wir es, um schnell auf Fehler zu stoßen, die während des normalen Betriebs nicht auftreten sollten oder auf die wir nicht vorbereitet sind.

In der Beschreibung Ihres Anwendungsfalls würde ich argumentieren, dass Sie einen Fehler auslösen und die Fehler behandeln sollten. Ich würde weiter argumentieren, dass es eine gute Vorgehensweise ist, den Fehlerstatus zu überprüfen, wenn einer von der Funktion bereitgestellt wird, die Sie verwenden, und dass der Benutzer überprüfen sollte, ob einer in der Dokumentation enthalten ist.

Panics Ich würde verwenden, um die Ausführung zu stoppen, wenn ich über einen Fehler, der von der Funktion zurückgegeben wird, die Sie schreiben, die ich überprüfe und keine Möglichkeit zum Wiederherstellen von haben.