Nach langjähriger Erfahrung mit PHP und JS bin ich es gewohnt, einen Stack-Trace in den Fehlern zu haben und den Ort, an dem der Fehler aufgetreten ist, direkt aus dem Fehlerbericht zu betrachten. Als ich vor ein paar Jahren auf Go neu gesät habe, war ich etwas überrascht, dass Go andere Regeln hat und Sie den Stack-Trace in einer Zeile wie "ungültiges Zeichen" erraten müssen. Und wenn es auf dem Produkt passiert ist und nicht bekannt ist, wie man es reproduziert, dann wurde dies zu einer ganzen Attraktion.
Da ich sicher bin, dass niemand darunter gelitten hat, habe ich ein Paket erstellt, das dies kann:
→
GitHubAlles was er tut ist:
- Fügt Fehlern eine Stapelverfolgung hinzu.
- Zeigt die Stapelverfolgung und die Quellfragmente an, bei denen dieser Fehler aufgetreten ist (natürlich bei Vorhandensein der Quelle).
Stack-Trace hinzufügen
Es gibt verschiedene Möglichkeiten, einen Fehler mit einem Stack-Trace zu erstellen:
Wenn der Fehler erneut verpackt wird, bleibt die Stapelverfolgung unverändert und wird nicht überschrieben. Dies ist praktisch, wenn nicht bekannt ist, ob der Fehler bereits eine Stapelverfolgung enthält oder nicht.
Der Code könnte ungefähr so aussehen:
func decodeFile(path string, data interface{}) error { b, err := ioutil.ReadFile(path) if err != nil { return tracerr.Wrap(err) } err = json.Unmarshal(b, data)
Stapelverfolgungsanzeige
Nach dem Fehler durch 100500,
if err != nil { return err } in
main() (oder wo es verarbeitet wird) in sein Heimatland zurückkehrt, möchten Sie es höchstwahrscheinlich anzeigen oder verpfänden.
Hierfür gibt es mehrere Optionen: Alle arbeiten als Drucken (druckt Text) oder Sprint (gibt Text zurück):
1) Fehlertext und Stack-Trace anzeigen:
tracerr.Print(err)
2) Zeigen Sie den Fehlertext, die Stapelverfolgung und das Quellfragment an (standardmäßig 6 Zeilen):
tracerr.PrintSource(err)
3) Das gleiche, aber in Farbe, normalerweise informativer:
tracerr.PrintSourceColor(err)
4) Sie können als Parameter übergeben, wie viele Codezeilen angezeigt werden sollen:
tracerr.PrintSource(err, 9) tracerr.PrintSourceColor(err, 9)
5) Oder übergeben Sie 2 optionale Parameter, wie viele vor und wie viele nach der Zeile mit dem anzuzeigenden Fehler:
tracerr.PrintSource(err, 5, 2) tracerr.PrintSourceColor(err, 5, 2)
Fragen
Ich habe bereits einige Rückmeldungen erhalten, daher erlaube ich mir, einige der bereits gestellten Fragen im Voraus zu beantworten.
F: Ist dies nur zum Debuggen geeignet? Es gibt einen Debugger.A: Dies ist nicht nur zum Debuggen geeignet, es ist auch möglich, Fehler mit Informationen über den Stack-Trace und sogar mit Fragmenten von Quellcodes auf dem Produkt zu protokollieren, da dies meiner Erfahrung nach die Analyse dieser Fehler erheblich vereinfacht.
F: Es gibt ein Super-Paket pkg / Fehler, warum nicht verwenden?A: Ja, ich selbst habe es komplett benutzt und bin froh, aber es hat mir aus folgenden Gründen nicht gepasst:
1) Es gibt keine einfache Möglichkeit, eine Stapelverfolgung sofort mit der Quelle anzuzeigen.
2) Wenn der Fehler erneut umbrochen wird (z. B. eine Ebene höher), wird die Stapelverfolgung durch weniger informative überschrieben.
3) Es ist unbedingt erforderlich, bei jeder Runde zusätzlichen Fehlertext zu senden, was mir beim Schreiben / Lesen von Code ein gewisser Aufwand ist.
F: In Go sind Fehler keine Ausnahmen und Sie können dies überhaupt nicht tun.A: Ich stimme zu, Fehler in Go sind keine Ausnahme. Wenn Sie es vorziehen, Tausende zu verarbeiten,
if err != nil { return err } andere Weise - dies ist natürlich Ihre Wahl. Sie können nur Fehler einschließen, die Sie als Ausnahmen behandeln.
F: Stectrace erhöht die Leistung.A: Ja, es wird hinzugefügt, aber dies ist nur für Stellen relevant, an denen Fehler in großen Mengen erzeugt werden. Fügen Sie dort nur keine Stapelverfolgung hinzu, wenn dies kritisch ist (ich bin sicher, dass dieser Overhead in den meisten Fällen vernachlässigbar ist).
Generell hoffe ich, dass dieses Paket Ihr Leben ein wenig erleichtert. Ich freue mich über jedes Feedback, danke.