Ich stimme zu, dass dies der beste Weg nach vorne ist: das Beheben des häufigsten Problems mit einem einfachen Design.

Ich möchte nicht bikeshed (zögern Sie nicht, dieses Gespräch zu verschieben), aber Rust ging dorthin und entschied sich schließlich mit dem Postfix-Operator ? und nicht mit einer eingebauten Funktion, um die Lesbarkeit zu verbessern.

Der Gophercon-Vorschlag zitiert ? in den erwogenen Ideen und nennt drei Gründe, warum er verworfen wurde: den ersten ("Steuerflussübertragungen werden in der Regel von Schlüsselwörtern begleitet") und den dritten ("Handler sind natürlicher definiert mit einem Schlüsselwort, also sollten auch Prüfungen") entfallen. Der zweite ist stilistisch: Er besagt, dass der Postfix-Operator, selbst wenn er besser für die Verkettung funktioniert, in einigen Fällen immer noch schlechter lesen kann, wie zum Beispiel:

check io.Copy(w, check newReader(foo))

eher, als:

io.Copy(w, newReader(foo)?)?

aber jetzt hätten wir:

try(io.Copy(w, try(newReader(foo))))

was meiner Meinung nach eindeutig die schlechtere der drei ist, da es nicht einmal mehr offensichtlich ist, welche Hauptfunktion aufgerufen wird.

Der Kern meines Kommentars ist also, dass alle drei Gründe, die im Gophercon-Vorschlag für die Nichtverwendung von ? angeführt werden, auf diesen try -Vorschlag nicht zutreffen; ? ist prägnant, gut lesbar, verdeckt nicht die Anweisungsstruktur (mit seiner internen Funktionsaufrufhierarchie) und ist verkettbar. Es entfernt noch mehr Unordnung aus der Sicht, während es den Kontrollfluss nicht mehr verdeckt, als es das vorgeschlagene try() bereits tut.

Um klarzustellen:

Tut

func f() (n int, err error) {
  n = 7
  try(errors.New("x"))
  // ...
}

Rückgabe (0, "x") oder (7, "x")? Ich würde letzteres vermuten.

Muss die Fehlerrückgabe in dem Fall benannt werden, in dem es keine Dekoration oder Handhabung gibt (wie in einer internen Hilfsfunktion)? Ich würde nicht annehmen.

Ihr Beispiel gibt 7, errors.New("x") zurück. Dies sollte aus dem vollständigen Dokument hervorgehen, das bald eingereicht wird (https://golang.org/cl/180557).

Der Fehlerergebnisparameter muss nicht benannt werden, um try zu verwenden. Es muss nur benannt werden, wenn die Funktion in einer zurückgestellten Funktion oder anderswo darauf verweisen muss.

Ich bin wirklich unzufrieden mit einer eingebauten _Funktion_, die den Kontrollfluss des Aufrufers beeinflusst. Ich schätze die Unmöglichkeit, neue Schlüsselwörter in Go 1 hinzuzufügen, aber dieses Problem mit magischen integrierten Funktionen zu umgehen, erscheint mir einfach falsch. Das Spiegeln anderer integrierter Elemente hat keine so unvorhersehbaren Ergebnisse wie das Ändern des Kontrollflusses.

Ich mag nicht, wie Postfix ? aussieht, aber ich denke, es schlägt immer noch try() .

Bearbeiten: Nun, ich habe es geschafft, völlig zu vergessen, dass Panik existiert und kein Schlüsselwort ist.

Der detaillierte Vorschlag ist jetzt hier (ausstehende Formatierungsverbesserungen, in Kürze) und wird hoffentlich viele Fragen beantworten.

@dominikh Der detaillierte Vorschlag diskutiert dies ausführlich, aber bitte beachten Sie, dass panic und recover zwei eingebaute Elemente sind, die sich auch auf den Kontrollfluss auswirken.

Eine Klarstellung / Verbesserungsvorschlag:

if the last argument supplied to try, of type error, is not nil, the enclosing function’s error result variable (...) is set to that non-nil error value before the enclosing function returns

Könnte hier stattdessen is set to that non-nil error value and the enclosing function returns ? (s/vor/und)

Beim ersten Lesen sah before the enclosing function returns so aus, als würde es den Fehlerwert irgendwann in der Zukunft setzen, kurz bevor die Funktion zurückkehrte - möglicherweise in einer späteren Zeile. Die korrekte Interpretation ist, dass try dazu führen kann, dass die aktuelle Funktion zurückkehrt. Das ist ein überraschendes Verhalten für die aktuelle Sprache, daher wäre ein klarerer Text zu begrüßen.

Ich denke, das ist nur Zucker, und eine kleine Anzahl von lautstarken Gegnern hat Golang über die wiederholte Verwendung von if err != nil ... gehänselt, und jemand hat es ernst genommen. Ich denke nicht, dass es ein Problem ist. Die einzigen fehlenden Dinge sind diese beiden integrierten Funktionen:

https://github.com/purpleidea/mgmt/blob/a235b760dc3047a0d66bb0b9d63c25bc746ed274/util/errwrap/errwrap.go#L26

Ich bin mir nicht sicher, warum jemand jemals eine Funktion wie diese schreiben würde, aber wofür wäre die vorgesehene Ausgabe

try(foobar())

Wenn foobar (error, error) zurückgegeben hat

Ich ziehe meine früheren Bedenken bezüglich des Kontrollflusses zurück und schlage nicht länger vor, ? zu verwenden. Ich entschuldige mich für die spontane Antwort (obwohl ich darauf hinweisen möchte, dass dies nicht passiert wäre, wenn das Problem eingereicht worden wäre, _nachdem_ der vollständige Vorschlag verfügbar war).

Ich bin nicht einverstanden mit der Notwendigkeit einer vereinfachten Fehlerbehandlung, aber ich bin sicher, dass dies ein verlorener Kampf ist. try , wie im Vorschlag dargelegt, scheint der am wenigsten schlechte Weg zu sein, dies zu tun.

@webermaster Nur das letzte error Ergebnis ist speziell für den an try übergebenen Ausdruck, wie im Proposal-Dokument beschrieben.

Wie @dominikh stimme auch ich der Notwendigkeit einer vereinfachten Fehlerbehandlung nicht zu.

Es verschiebt vertikale Komplexität in horizontale Komplexität, was selten eine gute Idee ist.

Wenn ich mich jedoch unbedingt zwischen Vorschlägen zur Vereinfachung der Fehlerbehandlung entscheiden müsste, wäre dies mein bevorzugter Vorschlag.

Es wäre hilfreich, wenn dies (in einem gewissen Stadium der Akzeptanz) von einem Tool begleitet werden könnte, um den Go-Code so umzuwandeln, dass er try in einer Teilmenge von fehlerrückgebenden Funktionen verwendet, wo eine solche Transformation leicht ohne durchgeführt werden kann Semantik ändern. Drei Vorteile fallen mir ein:

• Bei der Bewertung dieses Vorschlags würde es den Leuten ermöglichen, schnell ein Gefühl dafür zu bekommen, wie try in ihrer Codebasis verwendet werden könnte.
• Wenn try in einer zukünftigen Version von Go landet, werden die Leute wahrscheinlich ihren Code ändern wollen, um davon Gebrauch zu machen. Ein Tool zur Automatisierung der einfachen Fälle zu haben, wird sehr hilfreich sein.
• Eine Möglichkeit zu haben, eine große Codebasis schnell für die Verwendung try umzuwandeln, macht es einfach, die Auswirkungen der Implementierung in großem Maßstab zu untersuchen. (Korrektheit, Leistung und Codegröße zum Beispiel.) Die Implementierung kann jedoch einfach genug sein, um dies zu einer vernachlässigbaren Überlegung zu machen.

Ich möchte nur zum Ausdruck bringen, dass ich denke, dass ein bloßes try(foo()) , das tatsächlich aus der aufrufenden Funktion aussteigt, uns den visuellen Hinweis nimmt, dass sich der Funktionsfluss abhängig vom Ergebnis ändern kann.

Ich habe das Gefühl, dass ich mit try arbeiten kann, wenn ich mich genug daran gewöhnt habe, aber ich glaube auch, dass wir zusätzliche IDE-Unterstützung (oder so etwas) brauchen werden, um try hervorzuheben und den impliziten Fluss in Code-Reviews effizient zu erkennen /Debugging-Sitzungen

Was mir am meisten Sorgen macht, ist die Notwendigkeit, benannte Rückgabewerte zu haben, nur damit die defer-Anweisung glücklich ist.

Ich denke, das allgemeine Fehlerbehandlungsproblem, über das sich die Community beschwert, ist eine Kombination aus der Textbausteine ​​von if err != nil UND dem Hinzufügen von Kontext zu Fehlern. Die FAQ besagt eindeutig, dass letzteres absichtlich als separates Problem weggelassen wird, aber ich habe das Gefühl, dass dies dann zu einer unvollständigen Lösung wird, aber ich bin bereit, ihm eine Chance zu geben, nachdem ich über diese beiden Dinge nachgedacht habe:

1. Deklarieren Sie am Anfang der Funktion err .
   Funktioniert das? Ich erinnere mich an Probleme mit zurückgestellten und unbenannten Ergebnissen. Wenn dies nicht der Fall ist, muss der Vorschlag dies berücksichtigen.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

1. Weisen Sie Werte wie in der Vergangenheit zu, aber verwenden Sie eine wrapf -Hilfsfunktion, die die if err != nil -Boilerplate enthält.

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

Wenn beide funktionieren, kann ich damit umgehen.

func sample() (string, error) {
  var err error
  defer fmt.HandleErrorf(&err, "whatever")
  s := try(f())
  return s, nil
}

Das wird nicht funktionieren. Die Verzögerung aktualisiert die lokale Variable err , die nichts mit dem Rückgabewert zu tun hat.

func sample() (string, error) {
  s, err := f()
  try(wrapf(err, "whatever"))
  return s, nil
}
func wrapf(err error, format string, ...v interface{}) error {
  if err != nil {
    // err = wrapped error
  }
  return err
}

Das sollte funktionieren. Wrapf wird jedoch auch bei einem Null-Fehler aufgerufen.
Dies wird auch (weiterhin) funktionieren und ist meiner Meinung nach viel klarer:

func sample() (string, error) {
  s, err := f()
  if err != nil {
      return "", wrap(err)
  }
  return s, nil
}

Niemand wird Sie dazu zwingen, try zu verwenden.

Ich bin mir nicht sicher, warum jemand jemals eine Funktion wie diese schreiben würde, aber wofür wäre die vorgesehene Ausgabe

try(foobar())

Wenn foobar (error, error) zurückgegeben hat

Warum würden Sie mehr als einen Fehler von einer Funktion zurückgeben? Wenn Sie mehr als einen Fehler von der Funktion zurückgeben, sollte die Funktion vielleicht zunächst in zwei separate aufgeteilt werden, von denen jede nur einen Fehler zurückgibt.

Könnten Sie mit einem Beispiel näher darauf eingehen?

@cespare : Es sollte jemandem möglich sein, ein go fix zu schreiben, das vorhandenen Code umschreibt, der für try geeignet ist, sodass er try verwendet. Es kann nützlich sein, ein Gefühl dafür zu bekommen, wie vorhandener Code vereinfacht werden könnte. Wir erwarten keine signifikanten Änderungen in der Codegröße oder -leistung, da try nur syntaktischer Zucker ist, der ein gemeinsames Muster durch ein kürzeres Stück Quellcode ersetzt, das im Wesentlichen denselben Ausgabecode erzeugt. Beachten Sie auch, dass Code, der try verwendet, zwangsläufig eine Go-Version verwenden muss, die mindestens die Version ist, in der try eingeführt wurde.

@lestrrat : Einverstanden, dass man lernen muss, dass try den Kontrollfluss ändern kann. Wir vermuten, dass IDEs dies leicht genug hervorheben könnten.

@Goodwine : Wie @randall77 bereits betonte, wird Ihr erster Vorschlag nicht funktionieren. Eine Option, über die wir nachgedacht haben (aber in der Dokumentation nicht diskutiert), ist die Möglichkeit, eine vordeklarierte Variable zu haben, die das Ergebnis error bezeichnet (falls überhaupt eine vorhanden ist). Das würde die Notwendigkeit beseitigen, dieses Ergebnis zu benennen, nur damit es in einem defer verwendet werden kann. Aber das wäre noch magischer; es erscheint nicht gerechtfertigt. Das Problem bei der Benennung des Rückgabeergebnisses ist im Wesentlichen kosmetischer Natur, und das Wichtigste sind die automatisch generierten APIs, die von go doc und seinen Freunden bereitgestellt werden. Es wäre einfach, dies in diesen Tools anzugehen (siehe auch die FAQ des ausführlichen Designdokuments zu diesem Thema).

@nictuku : In Bezug auf Ihren Vorschlag zur Klarstellung (s/before/and/): Ich denke, der Code unmittelbar vor dem Absatz, auf den Sie sich beziehen, macht deutlich, was genau passiert, aber ich verstehe Ihren Punkt, s/before/and/ may machen die Prosa klarer. Ich werde die Änderung vornehmen.

Siehe CL 180637 .

Ich finde diesen Vorschlag eigentlich ganz gut. Allerdings habe ich einen Kritikpunkt. Der Ausstiegspunkt von Funktionen in Go wurde schon immer durch ein return gekennzeichnet. Paniken sind auch Ausstiegspunkte, aber das sind katastrophale Fehler, die normalerweise nie auftreten sollen.

Das Erstellen eines Ausstiegspunkts für eine Funktion, die kein return ist und alltäglich sein soll, kann zu viel weniger lesbarem Code führen. Ich hatte davon in einem Vortrag gehört und es ist schwer zu übersehen, wie schön dieser Code strukturiert ist:

func CopyFile(src, dst string) error {
    r, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    defer r.Close()

    w, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if _, err := io.Copy(w, r); err != nil {
        w.Close()
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }

    if err := w.Close(); err != nil {
        os.Remove(dst)
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
}

Dieser Code mag wie ein großes Durcheinander aussehen und war im Fehlerbehandlungsentwurf _gewollt_, aber vergleichen wir ihn mit try .

func CopyFile(src, dst string) error {
    defer func() {
        err = fmt.Errorf("copy %s %s: %v", src, dst, err)
    }()
    r, err := try(os.Open(src))
    defer r.Close()

    w, err := try(os.Create(dst))

    defer w.Close()
    defer os.Remove(dst)
    try(io.Copy(w, r))
    try(w.Close())

    return nil
}

Sie können sich das auf den ersten Blick ansehen und denken, dass es besser aussieht, weil es viel weniger wiederholten Code gibt. Es war jedoch sehr einfach, alle Stellen zu erkennen, die die Funktion im ersten Beispiel zurückgegeben hat. Sie waren alle eingerückt und begannen mit return , gefolgt von einem Leerzeichen. Dies liegt an der Tatsache, dass alle bedingten Rückgaben innerhalb von bedingten Blöcken stehen _müssen_ und daher durch gofmt -Standards eingerückt sind. return ist auch, wie bereits erwähnt, die einzige Möglichkeit, eine Funktion zu verlassen, ohne zu sagen, dass ein katastrophaler Fehler aufgetreten ist. Im zweiten Beispiel gibt es nur ein einziges return , also sieht es so aus, als ob die Funktion _ever_ nur nil zurückgeben sollte. Die letzten beiden try Aufrufe sind leicht zu sehen, aber die ersten beiden sind etwas schwieriger und wären sogar noch schwieriger, wenn sie irgendwo verschachtelt wären, dh so etwas wie proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) .

Die Rückkehr von einer Funktion scheint eine "heilige" Sache gewesen zu sein, weshalb ich persönlich der Meinung bin, dass alle Austrittspunkte einer Funktion mit return gekennzeichnet sein sollten.

Das hat schon mal jemand vor 5 Jahren umgesetzt. Wenn Sie interessiert sind, können Sie
Probieren Sie diese Funktion aus

https://news.ycombinator.com/item?id=20101417

Ich habe try() in Go vor fünf Jahren mit einem AST-Präprozessor implementiert und in echten Projekten verwendet, es war ziemlich nett: https://github.com/lunixbochs/og

Hier sind einige Beispiele, wie ich es in fehlerüberprüfungslastigen Funktionen verwende: https://github.com/lunixbochs/poxd/blob/master/tls.go#L13

Ich weiß die Mühe zu schätzen, die in diese Sache gesteckt wurde. Ich denke, es ist die beste Lösung, die ich bisher gesehen habe. Aber ich denke, es bringt eine Menge Arbeit beim Debuggen mit sich. Es ist mühsam, jedes Mal, wenn ich debugge, einen if-Block auszupacken und hinzuzufügen, und ihn neu zu verpacken, wenn ich fertig bin. Und ich habe auch etwas Angst vor der magischen err-Variablen, die ich berücksichtigen muss. Ich habe mich nie um die explizite Fehlerprüfung gekümmert, also bin ich vielleicht die falsche Person, um zu fragen. Es erschien mir immer als "bereit zum Debuggen".

@griesemer
Mein Problem mit Ihrer vorgeschlagenen Verwendung von defer als Möglichkeit zur Behandlung des Fehlerumbruchs besteht darin, dass das Verhalten aus dem von mir gezeigten Snippet (weiter unten) nicht sehr häufig AFAICT ist, und weil es sehr selten ist, kann ich mir vorstellen, dass Leute dies schreiben und denken, dass es funktioniert wenn nicht.

Zum Beispiel würde ein Anfänger das nicht wissen, wenn er deswegen einen Fehler hat, wird er nicht sagen "natürlich brauche ich eine benannte Rückgabe", er würde gestresst, weil es funktionieren sollte und es nicht tut.

var err error
defer fmt.HandleErrorf(err);

try ist bereits zu magisch, also können Sie genauso gut den ganzen Weg gehen und diesen impliziten Fehlerwert hinzufügen. Denken Sie an die Anfänger, nicht an diejenigen, die alle Nuancen von Go kennen. Wenn es nicht klar genug ist, denke ich nicht, dass es die richtige Lösung ist.

Oder ... Schlagen Sie nicht vor, defer so zu verwenden, versuchen Sie es mit einem anderen Weg, der sicherer, aber immer noch lesbar ist.

@deanveloper Es ist wahr, dass dieser Vorschlag (und übrigens jeder Vorschlag, der versucht, dasselbe zu versuchen) explizit sichtbare return -Anweisungen aus dem Quellcode entfernen wird - das ist schließlich der springende Punkt des Vorschlags. nicht wahr? Um die Textbausteine ​​von if -Anweisungen und returns zu entfernen, die alle gleich sind. Wenn Sie die return behalten möchten, verwenden Sie nicht try .

Wir sind daran gewöhnt, return -Anweisungen (und panic 's) sofort zu erkennen, da diese Art von Kontrollfluss in Go (und vielen anderen Sprachen) ausgedrückt wird. Es scheint nicht weit hergeholt, dass wir nach einiger Eingewöhnungszeit auch try als sich ändernden Kontrollfluss erkennen werden, genau wie wir es für return tun. Ich habe keinen Zweifel, dass eine gute IDE-Unterstützung auch dabei helfen wird.

Ich habe zwei Bedenken:

• benannte Rückgaben waren sehr verwirrend, und dies ermutigt sie mit einem neuen und wichtigen Anwendungsfall
• dies wird davon abhalten, Kontext zu Fehlern hinzuzufügen

Meiner Erfahrung nach ist das Hinzufügen von Kontext zu Fehlern unmittelbar nach jeder Aufrufseite entscheidend für Code, der leicht debuggt werden kann. Und benannte Rückgaben haben bei fast jedem Go-Entwickler, den ich kenne, irgendwann für Verwirrung gesorgt.

Ein kleinerer, stilistischer Aspekt ist, dass es unglücklich ist, wie viele Codezeilen jetzt in try(actualThing()) eingeschlossen werden. Ich kann mir vorstellen, die meisten Zeilen in einer Codebasis in try() zu sehen. Das fühlt sich unglücklich an.

Ich denke, diese Bedenken würden mit einer Optimierung angegangen:

a, b, err := myFunc()
check(err, "calling myFunc on %v and %v", a, b)

check() würde sich ähnlich verhalten wie try() , würde aber das Verhalten der generischen Übergabe von Funktionsrückgabewerten aufgeben und stattdessen die Möglichkeit bieten, Kontext hinzuzufügen. Es würde immer noch eine Rückkehr auslösen.

Dies würde viele der Vorteile von try() beibehalten:

• es ist ein eingebautes
• es folgt dem bestehenden Kontrollfluss WRT zum Verzögern
• Es passt gut zu der bestehenden Praxis, Fehlern Kontext hinzuzufügen
• Es stimmt mit aktuellen Vorschlägen und Bibliotheken für das Umschließen von Fehlern überein, wie z. B. errors.Wrap(err, "context message")
• es führt zu einer sauberen Call-Site: Es gibt keine Textbausteine ​​in der a, b, err := myFunc() -Zeile
• Das Beschreiben von Fehlern mit defer fmt.HandleError(&err, "msg") ist immer noch möglich, muss aber nicht gefördert werden.
• Die Signatur von check ist etwas einfacher, da sie keine beliebige Anzahl von Argumenten von der Funktion, die sie umschließt, zurückgeben muss.

@s4n-gt Danke für diesen Link. Ich war mir dessen nicht bewusst.

@Goodwine Point genommen. Der Grund dafür, keine direktere Fehlerbehandlungsunterstützung bereitzustellen, wird im Designdokument ausführlich erörtert. Fakt ist auch, dass im Laufe von etwa einem Jahr (seit der Veröffentlichung der Entwurfsentwürfe auf der letztjährigen Gophercon) keine zufriedenstellende Lösung für eine explizite Fehlerbehandlung gefunden wurde. Aus diesem Grund lässt dieser Vorschlag dies absichtlich weg (und schlägt stattdessen vor, ein defer zu verwenden). Dieser Vorschlag lässt noch die Tür für zukünftige Verbesserungen in dieser Hinsicht offen.

Der Vorschlag erwähnt das Ändern von Pakettests, damit Tests und Benchmarks einen Fehler zurückgeben können. Obwohl es keine „bescheidene Bibliotheksänderung“ wäre, könnten wir auch in Betracht ziehen, func main() error zu akzeptieren. Es würde das Schreiben kleiner Skripte viel schöner machen. Die Semantik wäre äquivalent zu:

func main() {
  if err := newmain(); err != nil {
    println(err.Error())
    os.Exit(1)
  }
}

Eine letzte Kritik. Nicht wirklich eine Kritik am Vorschlag selbst, sondern eine Kritik an einer gemeinsamen Antwort auf das Gegenargument "Funktion steuert den Fluss".

Die Antwort auf "Ich mag es nicht, dass eine Funktion den Ablauf steuert" ist, dass " panic auch den Ablauf des Programms steuert!". Es gibt jedoch ein paar Gründe, warum es für panic in Ordnung ist, dies zu tun, die nicht für try gelten.

1. panic ist freundlich zu Programmieranfängern, da es intuitiv ist und den Stack weiter auspackt. Man sollte nicht einmal nachschlagen müssen, wie panic funktioniert, um zu verstehen, was es tut. Programmieranfänger brauchen sich nicht einmal um recover zu kümmern, da Anfänger normalerweise keine Panikwiederherstellungsmechanismen bauen, zumal sie fast immer ungünstiger sind, als die Panik von vornherein zu vermeiden.

2. panic ist ein leicht zu erkennender Name. Es bringt Sorgen, und es muss. Wenn man panic in einer Codebasis sieht, sollte man sofort darüber nachdenken, wie man die Panik _vermeidet_, auch wenn es trivial ist.

3. Neben dem letzten Punkt kann panic nicht in einen Aufruf verschachtelt werden, wodurch es noch einfacher zu sehen ist.

Es ist in Ordnung, wenn Panik den Ablauf des Programms steuert, da es extrem leicht zu erkennen ist und es intuitiv ist, was es tut.

Die Funktion try erfüllt keinen dieser Punkte.

1. Man kann nicht erraten, was try tut, ohne die Dokumentation dafür nachzuschlagen. Viele Sprachen verwenden das Schlüsselwort auf unterschiedliche Weise, was es schwierig macht, zu verstehen, was es in Go bedeuten würde.

2. try fällt mir nicht ins Auge, besonders wenn es sich um eine Funktion handelt. _Besonders_ wenn die Syntaxhervorhebung sie als Funktion hervorhebt. _BESONDERS_ nach der Entwicklung in einer Sprache wie Java, wo try als unnötige Boilerplate angesehen wird (wegen geprüfter Ausnahmen).

3. try kann in einem Argument für einen Funktionsaufruf verwendet werden, wie in meinem Beispiel in meinem vorherigen Kommentar proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) . Dies macht es noch schwieriger zu erkennen.

Meine Augen ignorieren die try -Funktionen, auch wenn ich gezielt danach suche. Meine Augen werden sie sehen, aber sofort zu den Anrufen os.FindProcess oder strconv.Atoi springen. try ist eine bedingte Rückgabe. Sowohl Kontrollfluss als auch Rückgaben werden in Go auf Sockeln gehalten. Der gesamte Kontrollfluss innerhalb einer Funktion ist eingerückt und alle Rückgaben beginnen mit return . Das Mischen dieser beiden Konzepte zu einem leicht zu übersehenden Funktionsaufruf fühlt sich einfach ein bisschen daneben an.

Dieser und mein letzter Kommentar sind jedoch meine einzigen wirklichen Kritikpunkte an der Idee. Ich denke, ich mag diesen Vorschlag vielleicht nicht, aber ich denke immer noch, dass es ein Gesamtsieg für Go ist. Diese Lösung fühlt sich immer noch Go-ähnlicher an als die anderen Lösungen. Wenn dies hinzugefügt würde, wäre ich glücklich, aber ich denke, dass es noch verbessert werden kann, ich bin mir nur nicht sicher, wie.

@buchanae interessant. Wie geschrieben verschiebt es jedoch die Formatierung im fmt-Stil aus einem Paket in die Sprache selbst, was eine Dose mit Würmern öffnet.

Wie geschrieben verschiebt es jedoch die Formatierung im fmt-Stil aus einem Paket in die Sprache selbst, was eine Dose mit Würmern öffnet.

Guter Punkt. Ein einfacheres Beispiel:

a, b, err := myFunc()
check(err, "calling myFunc")

@buchanae Wir haben darüber nachgedacht, eine explizite Fehlerbehandlung direkter mit try zu verbinden - bitte sehen Sie sich das detaillierte Designdokument an, insbesondere den Abschnitt über Design-Iterationen. Ihr spezifischer Vorschlag von check würde nur erlauben, Fehler durch so etwas wie eine fmt.Errorf -ähnliche API (als Teil von check ) zu erweitern, wenn ich das richtig verstehe. Im Allgemeinen möchten die Leute vielleicht alle möglichen Dinge mit Fehlern machen und nicht nur eine neue erstellen, die über ihre Fehlerzeichenfolge auf die ursprüngliche verweist.

Auch dieser Vorschlag versucht nicht, alle Fehlerbehandlungssituationen zu lösen. Ich vermute, in den meisten Fällen macht try Sinn für Code, der jetzt im Wesentlichen so aussieht:

a, b, c, ... err := try(someFunctionCall())
if err != nil {
   return ..., err
}

Es gibt eine Menge Code, der so aussieht. Und nicht jedes Stück Code, das so aussieht, benötigt mehr Fehlerbehandlung. Und wo defer nicht richtig ist, kann man immer noch eine if -Anweisung verwenden.

Ich folge dieser Zeile nicht:

defer fmt.HandleErrorf(&err, “foobar”)

Es lässt den eingehenden Fehler auf den Boden fallen, was ungewöhnlich ist. Soll es eher so verwendet werden?

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

Die Vervielfältigung von err ist etwas stotternd. Dies bezieht sich nicht wirklich direkt auf den Vorschlag, sondern nur auf eine Randbemerkung zum Dokument.

Ich teile die beiden von @buchanae geäußerten Bedenken bezüglich benannter Rückgaben und kontextbezogener Fehler.

Ich finde benannte Rückgaben ein bisschen lästig, wie es ist; Ich denke, sie sind nur als Dokumentation wirklich nützlich. Sich stärker auf sie zu stützen, ist eine Sorge. Tut mir leid, dass ich so vage bin. Ich werde darüber mehr nachdenken und einige konkretere Gedanken liefern.

Ich denke, es gibt wirklich Bedenken, dass die Leute danach streben, ihren Code so zu strukturieren, dass try verwendet werden kann, und daher vermeiden, Kontext zu Fehlern hinzuzufügen. Dies ist ein besonders seltsamer Zeitpunkt, um dies einzuführen, da wir gerade jetzt bessere Möglichkeiten bieten, Fehlern durch offizielle Fehlerumbruchfunktionen Kontext hinzuzufügen.

Ich denke, dass try wie vorgeschlagen einige Codes erheblich schöner macht. Hier ist eine Funktion, die ich mehr oder weniger zufällig aus der Codebasis meines aktuellen Projekts ausgewählt habe, wobei einige der Namen geändert wurden. Besonders beeindruckt bin ich davon, wie try beim Zuweisen zu Struct-Feldern funktioniert. (Das setzt voraus, dass ich den Vorschlag richtig gelesen habe und dass dies funktioniert?)

Der vorhandene Code:

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations)
        if err != nil {
                return nil, err
        }
        t := &Thing{
                thingy: thingy,
        }
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil {
                return nil, err
        }
        t.initOtherThing()
        return t, nil
}

Mit try :

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

Kein Verlust an Lesbarkeit, außer vielleicht, dass es weniger offensichtlich ist, dass newScanner fehlschlagen könnte. Aber in einer Welt mit try Go würden Programmierer empfindlicher auf seine Anwesenheit reagieren.

@josharian In Bezug auf main , das ein error zurückgibt: Es scheint mir, dass Ihre kleine Hilfsfunktion alles ist, was benötigt wird, um den gleichen Effekt zu erzielen. Ich bin mir nicht sicher, ob das Ändern der Signatur von main gerechtfertigt ist.

Bezüglich des "foobar"-Beispiels: Es ist nur ein schlechtes Beispiel. Ich sollte es wahrscheinlich ändern. Danke, dass du es angesprochen hast.

defer fmt.HandleErrorf(&err, “foobar: %v”, err)

Das kann eigentlich nicht stimmen, da err zu früh ausgewertet wird. Es gibt ein paar Möglichkeiten, dies zu umgehen, aber keiner davon ist so sauber wie das ursprüngliche (ich denke, fehlerhafte) HandleErrorf. Ich denke, es wäre gut, ein oder zwei realistischere Beispiele für eine Hilfsfunktion zu haben.

BEARBEITEN: Dieser frühe Evaluierungsfehler ist in einem Beispiel vorhanden
am Ende des Dokuments:

defer fmt.HandleErrorf(&err, "copy %s %s: %v", src, dst, err)

@adg Ja, try kann so verwendet werden, wie Sie es in Ihrem Beispiel verwenden. Ich lasse Ihre Kommentare zu den benannten Renditen so stehen, wie sie sind.

Die Leute möchten vielleicht alle möglichen Dinge mit Fehlern tun und nicht nur eine neue erstellen, die über ihre Fehlerzeichenfolge auf die ursprüngliche verweist.

try versucht nicht, all die Dinge zu handhaben, die Leute mit Fehlern machen wollen, sondern nur die, die wir auf praktische Weise wesentlich einfacher machen können. Ich glaube, mein check -Beispiel geht in die gleiche Richtung.

Meiner Erfahrung nach ist die häufigste Form von Fehlerbehandlungscode Code, der im Wesentlichen einen Stack-Trace hinzufügt, manchmal mit zusätzlichem Kontext. Ich habe festgestellt, dass der Stack-Trace für das Debugging sehr wichtig ist, wo ich einer Fehlermeldung durch den Code folge.

Aber vielleicht werden andere Vorschläge allen Fehlern Stacktraces hinzufügen? Ich habe den Überblick verloren.

In dem von @adg gegebenen Beispiel gibt es zwei mögliche Fehler, aber keinen Kontext. Wenn newScanner und RunMigrations selbst keine Meldungen liefern, die Sie darauf hinweisen, welche falsch gelaufen ist, dann müssen Sie raten.

In dem von @adg gegebenen Beispiel gibt es zwei mögliche Fehler, aber keinen Kontext. Wenn newScanner und RunMigrations selbst keine Meldungen liefern, die Sie darüber informieren, bei welcher Methode ein Fehler aufgetreten ist, müssen Sie raten.

Das ist richtig, und das ist die Designentscheidung, die wir in diesem speziellen Codestück getroffen haben. Wir verpacken Fehler häufig in anderen Teilen des Codes.

Ich teile die Sorge wie @deanveloper und andere, dass dies das Debuggen erschweren könnte. Es ist wahr, dass wir uns dafür entscheiden können, es nicht zu verwenden, aber die Stile von Abhängigkeiten von Drittanbietern sind nicht unter unserer Kontrolle.
Wenn weniger sich wiederholendes if err := ... { return err } der Hauptpunkt ist, frage ich mich, ob eine "bedingte Rückgabe" ausreichen würde, wie https://github.com/golang/go/issues/27794 vorgeschlagen hat.

        return nil, err if f, err := os.Open(...)
        return nil, err if _, err := os.Write(...)

Ich denke, ? würde besser passen als try , und es wäre auch schwierig, defer immer nach Fehlern suchen zu müssen.

Dies schließt auch die Tore für Ausnahmen mit try/catch für immer.

Dies schließt auch die Tore für Ausnahmen, die try/catch für immer verwenden.

Ich bin _mehr_ damit einverstanden.

Ich stimme einigen der oben geäußerten Bedenken bezüglich des Hinzufügens von Kontext zu einem Fehler zu. Ich versuche langsam, davon abzukommen, nur einen Fehler zurückzugeben, um ihn immer mit einem Kontext zu dekorieren und ihn dann zurückzugeben. Mit diesem Vorschlag muss ich meine Funktion komplett ändern, um benannte Rückgabeparameter zu verwenden (was ich seltsam finde, weil ich kaum nackte Rückgaben verwende).

Wie @griesemer sagt:

Auch dieser Vorschlag versucht nicht, alle Fehlerbehandlungssituationen zu lösen. Ich vermute, in den meisten Fällen macht try Sinn für Code, der jetzt im Grunde so aussieht:
a, b, c, ... err := try(someFunctionCall())
wenn err != nil {
zurück ..., äh
}
Es gibt eine Menge Code, der so aussieht. Und nicht jedes Stück Code, das so aussieht, benötigt mehr Fehlerbehandlung. Und wo defer nicht richtig ist, kann man immer noch eine if-Anweisung verwenden.

Ja, aber sollte guter, idiomatischer Code ihre Fehler nicht immer umhüllen/dekorieren? Ich glaube, das ist der Grund, warum wir verfeinerte Fehlerbehandlungsmechanismen einführen, um Kontext-/Wrap-Fehler in stdlib hinzuzufügen. Wie ich sehe, scheint dieser Vorschlag nur den grundlegendsten Anwendungsfall zu berücksichtigen.

Darüber hinaus spricht dieser Vorschlag nur den Fall an, mehrere mögliche Fehlerrückgabestellen an einem _einzelnen Ort_ zu verpacken/dekorieren, wobei benannte Parameter mit einem Verzögerungsaufruf verwendet werden.

Aber es tut nichts für den Fall, wenn man verschiedene Kontexte zu verschiedenen Fehlern in einer einzigen Funktion hinzufügen muss. Zum Beispiel ist es sehr wichtig, die DB-Fehler zu dekorieren, um mehr Informationen darüber zu erhalten, woher sie kommen (vorausgesetzt, es gibt keine Stack-Traces).

Dies ist ein Beispiel für einen echten Code, den ich habe -

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    if err != nil {
        return err
    }
    var res int64
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table: %w", err)
    }

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    if err != nil {
        tx.Rollback()
        return fmt.Errorf("insert table2: %w", err)
    }
    return tx.Commit()
}

Laut Vorschlag:

Wenn eine Fehlererweiterung oder -umhüllung gewünscht wird, gibt es zwei Ansätze: Bleiben Sie bei der bewährten if-Anweisung oder „deklarieren“ Sie alternativ einen Fehlerbehandler mit einer defer-Anweisung:

Ich denke, dies wird in die Kategorie "bleib bei der bewährten if-Anweisung" fallen. Ich hoffe, dass der Vorschlag verbessert werden kann, um auch dies anzugehen.

Ich empfehle dem Go-Team dringend, Generika zu priorisieren , da Go dort die meiste Kritik hört, und auf die Fehlerbehandlung zu warten. Die heutige Technik ist nicht so schmerzhaft (obwohl go fmt sie auf einer Linie sitzen lassen sollte).

Das try() Konzept hat alle Probleme von check von check/handle:

1. Es liest sich nicht wie Go. Die Leute wollen eine Zuweisungssyntax ohne den anschließenden Nulltest, da das wie Go aussieht. Dreizehn separate Antworten auf check/handle legten dies nahe; siehe _Wiederkehrende Themen_ hier:
   https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

   f, #      := os.Open(...) // return on error
   f, #panic := os.Open(...) // panic on error
   f, #hname := os.Open(...) // invoke named handler on error
   // # is any available symbol or unambiguous pair
   

2. Das Verschachteln von Funktionsaufrufen, die Fehler zurückgeben, verschleiert die Reihenfolge der Operationen und behindert das Debuggen. Der Sachverhalt beim Auftreten eines Fehlers und damit die Aufrufreihenfolge sollte klar sein, ist es hier aber nicht:
   try(step4(try(step1()), try(step3(try(step2())))))
   Denken Sie jetzt daran, dass die Sprache Folgendes verbietet:
   f(t ? a : b) und f(a++)

3. Es wäre trivial, Fehler ohne Kontext zurückzugeben. Ein Schlüsselgrund für Check/Handle war die Förderung der Kontextualisierung.

4. Es ist an den Typ error und den letzten Rückgabewert gebunden. Wenn wir andere Rückgabewerte/-typen auf Ausnahmezustände untersuchen müssen, sind wir wieder bei: if errno := f(); errno != 0 { ... }

5. Es bietet nicht mehrere Wege. Code, der Speicher- oder Netzwerk-APIs aufruft, behandelt solche Fehler anders als Fehler aufgrund falscher Eingaben oder unerwarteter interner Zustände. Mein Code macht eines davon viel öfter als return err :

   • log.Fatal()
   • panic() für Fehler, die niemals auftreten sollten
   • Protokollieren Sie eine Nachricht und versuchen Sie es erneut

@gopherbot fügt Go2, LanguageChange hinzu

Wie wäre es, wenn Sie nur ? verwenden, um das Ergebnis genau wie rust auszupacken

Der Grund, warum wir dem Aufruf von try() skeptisch gegenüberstehen, könnte in zwei impliziten Bindungen liegen. Wir können die Bindung für den Rückgabewertfehler und die Argumente für try() nicht sehen. Für try() können wir eine Regel aufstellen, dass wir try() mit einer Argumentfunktion verwenden müssen, die einen Fehler in den Rückgabewerten hat. Aber die Bindung an Rückgabewerte ist nicht. Ich denke also, dass mehr Ausdruck erforderlich ist, damit Benutzer verstehen, was dieser Code tut.

func doSomething() (int, %error) {
  f := try(foo())
  ...
}

• Wir können try() nicht verwenden, wenn doSomething nicht %error in Rückgabewerten hat.
• Wir können try() nicht verwenden, wenn foo() keinen Fehler im letzten Rückgabewert hat.

Es ist schwierig, der bestehenden Syntax neue Anforderungen/Features hinzuzufügen.

Um ehrlich zu sein, denke ich, dass foo() auch %error haben sollte.

Fügen Sie eine weitere Regel hinzu

• %error kann nur einer in der Rückgabewertliste einer Funktion sein.

Im ausführlichen Designdokument ist mir aufgefallen, dass in einer früheren Iteration vorgeschlagen wurde, einen Fehlerbehandler an die eingebaute Funktion try zu übergeben. So was:

handler := func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
}

f := try(os.Open(filename), handler)  

oder noch besser so:

f := try(os.Open(filename), func(err error) error {
        return fmt.Errorf("foo failed: %v", err)  // wrap error
})  

Obwohl dies, wie das Dokument feststellt, mehrere Fragen aufwirft, denke ich, dass dieser Vorschlag weitaus wünschenswerter und nützlicher wäre, wenn er diese Möglichkeit beibehalten hätte, optional eine solche Fehlerbehandlungsfunktion oder -schließung zu spezifizieren.

Zweitens stört es mich nicht, dass eine eingebaute Funktion dazu führen kann, dass die Funktion zurückkehrt, aber, um ein bisschen Fahrrad zu werfen, der Name „versuchen“ ist zu kurz, um darauf hinzuweisen, dass es eine Rückkehr verursachen kann. Daher scheint mir ein längerer Name wie attempt besser zu sein.

BEARBEITEN: Drittens sollte Go-Sprache idealerweise zuerst Generika erhalten, wobei ein wichtiger Anwendungsfall die Möglichkeit wäre, diese Try-Funktion als Generika zu implementieren, damit das Bikeshedding enden kann und jeder die Fehlerbehandlung erhalten kann, die er selbst bevorzugt.

Hacker-News haben einen Sinn: try verhält sich nicht wie eine normale Funktion (sie kann zurückkehren), also ist es nicht gut, ihr eine funktionsähnliche Syntax zu geben. Eine return oder defer Syntax wäre besser geeignet:

func CopyFile(src, dst string) (err error) {
        r := try os.Open(src)
        defer r.Close()

        w := try os.Create(dst)
        defer func() {
                w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try io.Copy(w, r)
        try w.Close()
        return nil
}

@sheerun Das übliche Gegenargument dazu ist, dass panic auch eine eingebaute Funktion ist, die den Kontrollfluss verändert. Ich persönlich bin dagegen, aber es ist richtig.

1. In Anlehnung an @deanveloper oben und ähnliche Kommentare anderer befürchte ich sehr, dass wir die Kosten für das Hinzufügen eines neuen, etwas subtilen und – insbesondere wenn es in andere Funktionsaufrufe eingebettet ist – leicht zu übersehenden Schlüsselworts unterschätzen, das die Steuerung des Aufrufstapels verwaltet fließen. panic(...) ist eine relativ klare Ausnahme (Wortspiel nicht beabsichtigt) von der Regel, dass return der einzige Ausweg aus einer Funktion ist. Ich denke nicht, dass wir seine Existenz als Rechtfertigung dafür verwenden sollten, ein drittes hinzuzufügen.
2. Dieser Vorschlag würde die Rückgabe eines nicht umschlossenen Fehlers als Standardverhalten kanonisieren und Umbruchfehler als etwas degradieren, für das Sie sich mit zusätzlicher Zeremonie entscheiden müssen. Aber nach meiner Erfahrung ist das genau rückwärts zu guter Praxis. Ich hoffe, dass ein Vorschlag in diesem Bereich es einfacher oder zumindest nicht schwieriger machen würde, Kontextinformationen zu Fehlern an der Fehlerstelle hinzuzufügen.

vielleicht können wir mit dieser Semantik eine Variante mit optionaler Erweiterungsfunktion hinzufügen, etwa tryf :

func tryf(t1 T1, t1 T2, … tn Tn, te error, fn func(error) error) (T1, T2, … Tn)

übersetzt dies

x1, x2, … xn = tryf(f(), func(err error) { return fmt.Errorf("foobar: %q", err) })

das mögen

t1, … tn, te := f()
if te != nil {
    if fn != nil {
        te = fn(te)
    }
    err = te
    return
}

Da dies eine explizite Wahl ist (anstatt try zu verwenden), können wir vernünftige Antworten auf die Fragen in der früheren Version dieses Designs finden. Wenn die Erweiterungsfunktion beispielsweise nil ist, tun Sie nichts und geben Sie nur den ursprünglichen Fehler zurück.

Ich befürchte, dass try die traditionelle Fehlerbehandlung verdrängen wird und dass dies das Kommentieren von Fehlerpfaden dadurch erschweren wird.

Code, der Fehler behandelt, indem er Nachrichten protokolliert und Telemetriezähler aktualisiert, wird sowohl von Linters als auch von Entwicklern als fehlerhaft oder unangemessen angesehen, die erwarten, dass alles try wird.

a, b, err := doWork()
if err != nil {
  updateCounters()
  writeLogs()
  return err
}

Go ist eine äußerst soziale Sprache mit gemeinsamen Redewendungen, die durch Werkzeuge (fmt, lint usw.) erzwungen werden. Bitte behalten Sie die gesellschaftlichen Auswirkungen dieser Idee im Hinterkopf - es wird eine Tendenz geben, sie überall verwenden zu wollen.

@Politiker , Entschuldigung, aber das gesuchte Wort ist nicht _social_, sondern _opinionated_. Go ist eine rechthaberische Programmiersprache. Im Übrigen stimme ich dem, worauf Sie hinauswollen, weitgehend zu.

@beoran Community-Tools wie Godep und die verschiedenen Linters zeigen, dass Go sowohl eigensinnig als auch sozial ist, und viele der Dramen mit der Sprache stammen aus dieser Kombination. Hoffentlich können wir uns beide darauf einigen, dass try nicht das nächste Drama sein sollte.

@politiker Danke für die Klarstellung, so hatte ich das nicht verstanden. Ich kann sicherlich zustimmen, dass wir versuchen sollten, Drama zu vermeiden.

Ich bin verwirrt darüber.

Aus dem Blog: Fehler sind Werte , aus meiner Sicht sollen sie geschätzt und nicht ignoriert werden.

Und ich glaube, was Rop Pike gesagt hat: "Werte können programmiert werden, und da Fehler Werte sind, können Fehler programmiert werden."

Wir sollten error nicht als exception betrachten, es ist, als würden wir Komplexität nicht nur zum Denken, sondern auch zum Codieren importieren, wenn wir dies tun.

"Verwenden Sie die Sprache, um Ihre Fehlerbehandlung zu vereinfachen." - Rob Pike

Und mehr noch, wir können diese Folie überprüfen

Eine Situation, in der ich die Fehlerprüfung über if besonders umständlich finde, ist das Schließen von Dateien (z. B. auf NFS). Ich denke, derzeit sollen wir Folgendes schreiben, ob Fehlerrückgaben von .Close() möglich sind?

r, err := os.Open(src)
if err != nil {
    return err
}
defer func() {
    // maybe check whether a previous error occured?
    return r.Close()
}()

Könnte defer try(r.Close()) eine gute Möglichkeit sein, eine handhabbare Syntax für den Umgang mit solchen Fehlern zu haben? Zumindest wäre es sinnvoll, das Beispiel CopyFile() im Vorschlag irgendwie anzupassen, um Fehler von r.Close() und w.Close() nicht zu ignorieren.

@seehuhn Ihr Beispiel wird nicht kompiliert, da die verzögerte Funktion keinen Rückgabetyp hat.

func doWork() (err error) {
  r, err := os.Open(src)
  if err != nil {
    return err
  }
  defer func() {
    err = r.Close()  // overwrite the return value
  }()
}

Funktioniert wie erwartet. Der Schlüssel ist der benannte Rückgabewert.

Ich mag den Vorschlag, aber ich denke, dass das Beispiel von @seehuhn auch angesprochen werden sollte:

defer try(w.Close())

würde den Fehler von Close() nur zurückgeben, wenn der Fehler nicht bereits gesetzt war.
Dieses Muster wird so oft verwendet...

Ich stimme den Bedenken hinsichtlich des Hinzufügens von Kontext zu Fehlern zu. Ich sehe es als eine der besten Methoden, die Fehlermeldungen sehr freundlich (und klar) hält und den Debug-Prozess vereinfacht.

Das erste, woran ich dachte, war, fmt.HandleErrorf durch eine tryf -Funktion zu ersetzen, die dem Fehler zusätzlichen Kontext voranstellt.

func tryf(t1 T1, t1 T2, … tn Tn, te error, ts string) (T1, T2, … Tn)

Zum Beispiel (von einem echten Code, den ich habe):

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil {
        return nil, errors.WithMessage(err, "load config dir")
    }
    b := bytes.NewBuffer(nil)
    if err = templates.ExecuteTemplate(b, "main", c); err != nil {
        return nil, errors.WithMessage(err, "execute main template")
    }
    buf, err := format.Source(b.Bytes())
    if err != nil {
        return nil, errors.WithMessage(err, "format main template")
    }
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    if err := ioutil.WriteFile(target, buf, 0644); err != nil {
        return nil, errors.WithMessagef(err, "write file %s", target)
    }
    // ...
}

Kann geändert werden in etwas wie:

func (c *Config) Build() error {
    pkgPath := tryf(c.load(), "load config dir")
    b := bytes.NewBuffer(nil)
    tryf(emplates.ExecuteTemplate(b, "main", c), "execute main template")
    buf := tryf(format.Source(b.Bytes()), "format main template")
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    tryf(ioutil.WriteFile(target, buf, 0644), fmt.Sprintf("write file %s", target))
    // ...
}

Oder, wenn ich das Beispiel von @agnivade nehme:

func (p *pgStore) DoWork() (err error) {
    tx := tryf(p.handle.Begin(), "begin transaction")
        defer func() {
        if err != nil {
            tx.Rollback()
        }
    }()
    var res int64
    tryf(tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res), "insert table")
    _, = tryf(tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res), "insert table2")
    return tryf(tx.Commit(), "commit transaction")
}

@josharian hat jedoch einen guten Punkt angesprochen, der mich bei dieser Lösung zögern lässt:

Wie geschrieben verschiebt es jedoch die Formatierung im fmt-Stil aus einem Paket in die Sprache selbst, was eine Dose mit Würmern öffnet.

Ich bin mit diesem Vorschlag voll und ganz einverstanden und kann seine Vorteile anhand einer Reihe von Beispielen erkennen.

Meine einzige Sorge bei dem Vorschlag ist die Benennung von try , ich habe das Gefühl, dass seine Konnotationen mit anderen Sprachen die Wahrnehmung der Entwickler über den Zweck verzerren können, wenn sie aus anderen Sprachen stammen. Hier kommt Java zum Einsatz.

Für mich würde ich bevorzugen, dass das Builtin pass heißt. Ich habe das Gefühl, dass dies eine bessere Darstellung dessen gibt, was passiert. Schließlich behandeln Sie den Fehler nicht, sondern geben ihn zurück, damit er vom Aufrufer behandelt werden kann. try vermittelt den Eindruck, dass der Fehler behandelt wurde.

Es ist ein Daumen nach unten von mir, hauptsächlich weil das Problem, das es ansprechen soll ("die Boilerplate if-Anweisungen, die typischerweise mit der Fehlerbehandlung verbunden sind") einfach kein Problem für mich ist. Wenn alle Fehlerprüfungen einfach if err != nil { return err } wären, dann könnte ich einen gewissen Wert darin sehen, dafür syntaktischen Zucker hinzuzufügen (obwohl Go von Natur aus eine relativ zuckerfreie Sprache ist).

Tatsächlich variiert das, was ich im Falle eines Nicht-Null-Fehlers tun möchte, ziemlich stark von einer Situation zur nächsten. Vielleicht möchte ich t.Fatal(err) . Vielleicht möchte ich eine schmückende Nachricht hinzufügen return fmt.Sprintf("oh no: %v", err) . Vielleicht protokolliere ich einfach den Fehler und fahre fort. Vielleicht setze ich ein Fehler-Flag für mein SafeWriter-Objekt und fahre fort, indem ich das Flag am Ende einer Reihe von Operationen überprüfe. Vielleicht muss ich andere Maßnahmen ergreifen. Nichts davon kann mit try automatisiert werden. Wenn also das Argument für try darin besteht, dass alle if err != nil -Blöcke eliminiert werden, ist dieses Argument nicht gültig.

Wird es _some_ von ihnen eliminieren? Sicher. Ist das ein attraktives Angebot für mich? Meh. Ich mache mir wirklich keine Sorgen. Für mich gehört if err != nil einfach zu Go, wie die geschweiften Klammern oder defer . Ich verstehe, dass es für Leute, die neu bei Go sind, ausführlich und sich wiederholend aussieht, aber Leute, die neu bei Go sind, sind aus einer ganzen Reihe von Gründen nicht am besten in der Lage, dramatische Änderungen an der Sprache vorzunehmen.

Die Messlatte für signifikante Änderungen an Go war traditionell, dass die vorgeschlagene Änderung ein Problem lösen muss, das (A) signifikant ist, (B) viele Menschen betrifft und (C) durch den Vorschlag gut gelöst ist. Ich bin in keinem dieser drei Kriterien überzeugt. Ich bin ziemlich zufrieden mit der Fehlerbehandlung von Go, so wie sie ist.

Um @peterbourgon und @deanveloper zu wiederholen, eines meiner Lieblingsdinge an Go ist, dass der Codefluss klar ist und panic() nicht wie ein Standard-Flusssteuerungsmechanismus behandelt wird, wie es in Python der Fall ist.

Was die Debatte über Panik betrifft, so erscheint panic() fast immer alleine in einer Zeile, weil es keinen Wert hat. Du kannst nicht fmt.Println(panic("oops")) . Dies erhöht seine Sichtbarkeit enorm und macht es weit weniger vergleichbar mit try() , als die Leute glauben.

Wenn es ein anderes Flusskontrollkonstrukt für Funktionen geben soll, würde ich _weit_ vorziehen, dass es sich um eine Anweisung handelt, die garantiert das Element ganz links in einer Zeile ist.

Eines der Beispiele im Vorschlag bringt das Problem für mich auf den Punkt:

func printSum(a, b string) error {
        fmt.Println(
                "result:",
                try(strconv.Atoi(a)) + try(strconv.Atoi(b)),
        )
        return nil
}

Der Kontrollfluss wird wirklich weniger offensichtlich und sehr undurchsichtig.

Dies widerspricht auch der ursprünglichen Absicht von Rob Pike, dass alle Fehler explizit behandelt werden müssen.

Während eine Reaktion darauf sein kann "dann nicht verwenden", ist das Problem -- andere Bibliotheken werden es verwenden, und das Debuggen, Lesen und Verwenden wird problematischer. Dies wird mein Unternehmen dazu motivieren, niemals go 2 zu übernehmen und nur Bibliotheken zu verwenden, die try nicht verwenden. Wenn ich damit nicht alleine bin, könnte es zu einer Division a-la Python 2/3 führen.

Außerdem impliziert die Benennung von try automatisch, dass schließlich catch in der Syntax auftaucht, und wir werden wieder Java sein.

Aus diesem Grund bin ich _stark_ gegen diesen Vorschlag.

Ich mag den Namen try nicht. Es impliziert einen _Versuch_, etwas mit einem hohen Misserfolgsrisiko zu tun (ich habe möglicherweise eine kulturelle Voreingenommenheit gegen _try_, da ich kein englischer Muttersprachler bin), während stattdessen try verwendet würde, falls wir seltene Fehler erwarten (Motivation für den Wunsch, die Ausführlichkeit der Fehlerbehandlung zu reduzieren) und optimistisch sind. Außerdem _fängt_ try in diesem Vorschlag tatsächlich einen Fehler, um es vorzeitig zurückzugeben. Ich mag den pass Vorschlag von @HiImJC.

Neben dem Namen finde ich es unangenehm, return -ähnliche Anweisungen jetzt in der Mitte von Ausdrücken zu haben. Dies bricht den Go-Flow-Stil. Es wird Code-Reviews schwieriger machen.

Im Allgemeinen finde ich, dass dieser Vorschlag nur dem faulen Programmierer zugute kommt, der jetzt eine Waffe für kürzeren Code und noch weniger Grund hat, sich die Mühe zu machen, Fehler zu umschließen. Da es auch Überprüfungen erschweren wird (Rückkehr in der Mitte des Ausdrucks), denke ich, dass dieser Vorschlag gegen das Ziel der „Programmierung im Maßstab“ von Go verstößt.

Eine meiner Lieblingssachen an Go, die ich im Allgemeinen sage, wenn ich die Sprache beschreibe, ist, dass es für die meisten Dinge nur einen Weg gibt, Dinge zu tun. Dieser Vorschlag widerspricht diesem Prinzip ein wenig, indem er mehrere Möglichkeiten bietet, dasselbe zu tun. Ich persönlich denke, dass dies nicht notwendig ist und dass es die Einfachheit und Lesbarkeit der Sprache eher beeinträchtigen als verbessern würde.

Ich finde diesen Vorschlag insgesamt gut. Die Interaktion mit defer scheint ausreichend zu sein, um einen Fehler auf ergonomische Weise zurückzugeben und gleichzeitig zusätzlichen Kontext hinzuzufügen. Obwohl es schön wäre, den Haken anzugehen, auf den @josharian hingewiesen hat, wie man den ursprünglichen Fehler in die umschlossene Fehlermeldung einfügt.

Was fehlt, ist eine ergonomische Art und Weise, wie dies mit dem/den Fehlerinspektionsvorschlag(en) auf dem Tisch interagiert. Ich glaube, APIs sollten sehr bewusst sein, welche Arten von Fehlern sie zurückgeben, und der Standardwert sollte wahrscheinlich "zurückgegebene Fehler sind in keiner Weise inspizierbar" sein. Es sollte dann einfach sein, in einen Zustand zu gelangen, in dem Fehler auf präzise Weise inspizierbar sind, wie durch die Funktionssignatur dokumentiert ("Es meldet einen Fehler der Art X in Umstand A und einen Fehler der Art Y in Umstand B").

Leider macht dieser Vorschlag ab sofort die ergonomischste Option zur unerwünschtesten (für mich); blindes Durchlaufen beliebiger Fehlerarten. Ich denke, das ist nicht wünschenswert, weil es dazu anregt, nicht darüber nachzudenken, welche Art von Fehlern Sie zurückgeben und wie Benutzer Ihrer API sie verwenden werden. Die zusätzliche Bequemlichkeit dieses Vorschlags ist sicherlich schön, aber ich fürchte, er wird schlechtes Verhalten fördern, da die wahrgenommene Bequemlichkeit den wahrgenommenen Wert überwiegen wird, sorgfältig darüber nachzudenken, welche Fehlerinformationen Sie bereitstellen (oder lecken).

Ein Pflaster wäre, wenn Fehler, die von try zurückgegeben werden, in Fehler umgewandelt werden, die nicht "auspackbar" sind. Leider hat dies auch ziemlich schwerwiegende Nachteile, da es dazu führt, dass defer die Fehler selbst nicht untersuchen kann. Außerdem verhindert es die Verwendung, bei der try tatsächlich einen Fehler der erwünschten Art zurückgibt (d. h. Anwendungsfälle, bei denen try vorsichtig und nicht fahrlässig verwendet wird).

Eine andere Lösung wäre, die (verworfene) Idee, ein optionales zweites Argument für try zu haben, um die Fehlerart(en) zu definieren/auf die weiße Liste zu setzen, die von dieser Site zurückgegeben werden können. Dies ist etwas mühsam, da wir zwei verschiedene Möglichkeiten haben, eine "Fehlerart" zu definieren, entweder nach Wert ( io.EOF usw.) oder nach Typ ( *os.PathError , *exec.ExitError ). Es ist einfach, Fehlerarten anzugeben, die Werte als Argumente für eine Funktion sind, aber es ist schwieriger, Typen anzugeben. Ich bin mir nicht sicher, wie ich damit umgehen soll, aber wirf die Idee raus.

Das Problem, auf das @josharian hingewiesen hat, kann vermieden werden, indem die Auswertung von err verzögert wird:

defer func() { fmt.HandleErrorf(&err, "oops: %v", err) }()

Sieht nicht toll aus, sollte aber funktionieren. Ich würde es jedoch vorziehen, wenn dies durch Hinzufügen eines neuen Formatierungsverbs/-flags für Fehlerzeiger oder vielleicht für Zeiger im Allgemeinen behoben werden kann, das den dereferenzierten Wert wie bei einfachem %v druckt. Nennen wir es für das Beispiel %*v :

defer fmt.HandleErrorf(&err, "oops: %*v", &err)

Abgesehen von dem Haken beiseite, ich denke, dass dieser Vorschlag vielversprechend aussieht, aber es scheint entscheidend zu sein, die Ergonomie des Hinzufügens von Kontext zu Fehlern in Schach zu halten.

Bearbeiten:

Ein anderer Ansatz besteht darin, den Fehlerzeiger in eine Struktur einzuschließen, die Stringer implementiert:

type wraperr struct{ err *error }
func (w wraperr) String() string { return (*w.err).Error() }

...

defer handleErrorf(&err, "oops: %v", wraperr{&err})

Paar Dinge aus meiner Sicht. Warum sind wir so besorgt darüber, ein paar Codezeilen einzusparen? Ich betrachte dies ähnlich wie kleine Funktionen als schädlich .

Außerdem finde ich, dass ein solcher Vorschlag die Verantwortung für die korrekte Behandlung des Fehlers einer "Magie" entziehen würde, von der ich befürchte, dass sie nur missbraucht wird, und Faulheit fördern, die zu Code von schlechter Qualität und Fehlern führt.

Der Vorschlag hat, wie angegeben, auch eine Reihe unklarer Verhaltensweisen, sodass dies bereits problematischer ist als _explizit_ zusätzliche ~ 3 Zeilen, die klarer sind.

Wir verwenden das Zurückstellungsmuster derzeit nur sparsam im Haus. Es gibt hier einen Artikel, der ähnlich gemischt aufgenommen wurde, als wir ihn schrieben – https://bet365techblog.com/better-error-handling-in-go

Wir haben es jedoch in Erwartung des check / handle -Vorschlags verwendet.

Check/handle war ein viel umfassenderer Ansatz, um die Fehlerbehandlung in go prägnanter zu gestalten. Sein handle -Block behielt den gleichen Funktionsumfang bei wie der, in dem er definiert wurde, wohingegen alle defer -Anweisungen neue Kontexte mit einem noch so großen Overhead sind. Dies schien eher im Einklang mit den Idiomen von go zu stehen, da Sie, wenn Sie das Verhalten "nur den Fehler zurückgeben, wenn er auftritt" wollten, dies explizit als handle { return err } deklarieren könnten.

Defer ist offensichtlich darauf angewiesen, dass auch die err-Referenz beibehalten wird, aber wir haben gesehen, dass Probleme entstehen, wenn die Fehlerreferenz mit blockbezogenen Variablen verdeckt wird. Es ist also nicht idiotensicher genug, um als Standardmethode zur Fehlerbehandlung im Go angesehen zu werden.

try scheint in diesem Fall nicht allzu viel zu lösen, und ich teile die gleiche Befürchtung wie andere, dass dies einfach zu faulen Implementierungen führen würde oder zu solchen, die das Verzögerungsmuster überbeanspruchen.

Wenn die verzögerungsbasierte Fehlerbehandlung A Thing sein soll, sollte dem Fehlerpaket wahrscheinlich so etwas hinzugefügt werden:

        f := try(os.Create(filename))
        defer errors.Deferred(&err, f.Close)

Das Ignorieren der Fehler verzögerter Close-Anweisungen ist ein ziemlich häufiges Problem. Es sollte ein Standardtool geben, das dabei hilft.

Eine eingebaute Funktion, die zurückkehrt, ist schwerer zu verkaufen als ein Schlüsselwort, das dasselbe tut.
Ich würde es mehr mögen, wenn es ein Schlüsselwort wäre, wie es in Zig[1] ist.

1. https://ziglang.org/documentation/master/#try

Eingebaute Funktionen, deren Typsignatur nicht mit dem Typsystem der Sprache ausgedrückt werden kann und deren Verhalten verwirrt, was eine Funktion normalerweise ist, scheinen nur eine Notluke zu sein, die wiederholt verwendet werden kann, um die tatsächliche Sprachentwicklung zu vermeiden.

Wir sind es gewohnt, Return-Anweisungen (und Panik) sofort zu erkennen, weil diese Art von Kontrollfluss in Go (und vielen anderen Sprachen) ausgedrückt wird. Es scheint nicht weit hergeholt, dass wir nach einiger Eingewöhnungszeit auch try als sich ändernden Kontrollfluss erkennen werden, genau wie wir es für return tun. Ich habe keinen Zweifel, dass eine gute IDE-Unterstützung auch dabei helfen wird.

Ich halte das für ziemlich weit hergeholt. In Standardcode stimmt ein Return immer mit /^\t*return / überein – es ist ein sehr triviales Muster, das ohne Hilfe mit dem Auge zu erkennen ist. try hingegen kann überall im Code vorkommen, beliebig tief in Funktionsaufrufen verschachtelt. Selbst noch so viel Training wird uns nicht in die Lage versetzen, den gesamten Kontrollfluss in einer Funktion ohne Werkzeugunterstützung sofort zu erkennen.

Darüber hinaus ist ein Feature, das von "guter IDE-Unterstützung" abhängt, in allen Umgebungen im Nachteil, in denen es keine gute IDE-Unterstützung gibt. Code-Review-Tools fallen mir sofort ein – wird Gerrit alle Versuche für mich hervorheben? Was ist mit Leuten, die sich aus verschiedenen Gründen dafür entscheiden, keine IDEs oder ausgefallene Code-Hervorhebungen zu verwenden? Wird acme damit beginnen, try hervorzuheben?

Eine Sprachfunktion sollte von sich aus leicht verständlich sein und nicht von der Unterstützung eines Editors abhängen.

@kungfusheep Ich mag diesen Artikel. Wenn Sie sich um das Einschließen einer Verzögerung kümmern, erhöht sich die Lesbarkeit bereits erheblich, ohne try .

Ich bin in dem Lager, das Fehler in Go nicht wirklich als Problem empfindet. Trotzdem kann if err != nil { return err } bei einigen Funktionen ziemlich stottern. Ich habe Funktionen geschrieben, die nach fast jeder Anweisung eine Fehlerprüfung benötigten, und keine benötigte eine besondere Behandlung außer Wrap und Return. Manchmal gibt es einfach keine clevere Buffer-Struktur, die die Dinge schöner macht. Manchmal ist es nur ein anderer kritischer Schritt nach dem anderen und Sie müssen einfach kurzschließen, wenn etwas schief gelaufen ist.

Obwohl try diesen Code sicherlich viel einfacher und besser lesbar machen würde, während er vollständig abwärtskompatibel wäre, stimme ich zu, dass try kein kritisches Must-Have-Feature ist, also wenn die Leute zu viel Angst davor haben es ist vielleicht am besten, es nicht zu haben.

Die Semantik ist jedoch recht eindeutig. Jedes Mal, wenn Sie try sehen, folgt es entweder dem glücklichen Weg oder es kehrt zurück. Einfacher geht es wirklich nicht.

Dies sieht aus wie ein spezielles Case-Makro.

@dominikh try stimmt immer mit /try\(/ überein, also weiß ich nicht, was Sie wirklich sagen wollen. Es ist genauso durchsuchbar und jeder Editor, von dem ich je gehört habe, hat eine Suchfunktion.

@qrpnxz Ich denke, der Punkt, den er machen wollte, ist nicht, dass Sie nicht programmatisch danach suchen können, sondern dass es schwieriger ist, mit Ihren Augen danach zu suchen. Der reguläre Ausdruck war nur eine Analogie mit Betonung auf /^\t* , was bedeutet, dass sich alle Zeilenumbrüche deutlich dadurch abheben, dass sie am Anfang einer Zeile stehen (ohne führende Leerzeichen).

Wenn man genauer darüber nachdenkt, sollte es ein paar allgemeine Hilfsfunktionen geben. Vielleicht sollten sie in einem Paket namens "deferred" sein.

Wenn Sie den Vorschlag für ein check mit Format adressieren, um die Benennung der Rückgabe zu vermeiden, können Sie dies einfach mit einer Funktion tun, die auf nil prüft, so wie hier

func Format(err error, message string, args ...interface{}) error {
    if err == nil {
        return nil
    }
    return fmt.Errorf(...)
}

Dies kann ohne eine benannte Rückgabe wie folgt verwendet werden:

func foo(s string) (int, error) {
    n, err := strconv.Atoi(s)
    try(deferred.Format(err, "bad string %q", s))
    return n, nil
}

Der vorgeschlagene fmt.HandleError könnte stattdessen in das zurückgestellte Paket gestellt werden, und die Hilfsfunktion my errors.Defer könnte deferred.Exec heißen, und es könnte eine bedingte Ausführung für Prozeduren geben, die nur ausgeführt werden, wenn der Fehler nicht null ist.

Wenn Sie es zusammensetzen, erhalten Sie so etwas wie

func CopyFile(src, dst string) (err error) {
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r := try(os.Open(src))
    defer deferred.Exec(&err, r.Close)

    w := try(os.Create(dst))
    defer deferred.Exec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    try(io.Copy(w, r))

    return nil
}

Ein anderes Beispiel:

func (p *pgStore) DoWork() (err error) {
    tx := try(p.handle.Begin())

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(deferred.Format(err, "insert table")

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(deferred.Format(err, "insert table2"))

    return tx.Commit()
}

Dieser Vorschlag bringt uns von if err != nil überall zu try überall. Es verschiebt das vorgeschlagene Problem und löst es nicht.

Obwohl ich argumentieren würde, dass der aktuelle Fehlerbehandlungsmechanismus zunächst kein Problem darstellt. Wir müssen nur die Werkzeuge und die Überprüfung drumherum verbessern.

Außerdem würde ich argumentieren, dass if err != nil tatsächlich besser lesbar ist als try , weil es die Zeile der Geschäftslogiksprache nicht unübersichtlich macht, sondern direkt darunter sitzt:

file := try(os.OpenFile("thing")) // less readable than, 

file, err := os.OpenFile("thing")
if err != nil {

}

Und wenn Go in seiner Fehlerbehandlung magischer sein sollte, warum sollte man es nicht einfach vollständig besitzen. Zum Beispiel kann Go implizit das eingebaute try aufrufen, wenn ein Benutzer keinen Fehler zuweist. Zum Beispiel:

func getString() (string, error) { ... }

func caller() {
  defer func() {
    if err != nil { ... } // whether `err` must be defined or not is not shown in this example. 
  }

  // would call try internally, because a user is not 
  // assigning an error value. Also, it can add a compile error
  // for "defined and not used err value" if the user does not 
  // handle the error. 
  str := getString()
}

Für mich würde das das Redundanzproblem tatsächlich auf Kosten der Magie und der möglichen Lesbarkeit lösen.

Daher schlage ich vor, dass wir entweder das „Problem“ wie im obigen Beispiel wirklich lösen oder die aktuelle Fehlerbehandlung beibehalten, aber anstatt die Sprache zu ändern, um Redundanz und Wrapping zu lösen, ändern wir nicht die Sprache, sondern verbessern die Tools und die Überprüfung von Code, um das Erlebnis zu verbessern.

Zum Beispiel gibt es in VSCode ein Snippet namens iferr , wenn Sie es eingeben und die Eingabetaste drücken, wird es zu einer vollständigen Fehlerbehandlungsanweisung erweitert ... daher fühlt sich das Schreiben für mich nie ermüdend an und das spätere Lesen ist besser .

@josharian

Obwohl es keine „bescheidene Bibliotheksänderung“ wäre, könnten wir auch in Betracht ziehen, den Fehler von func main() zu akzeptieren.

Das Problem dabei ist, dass nicht alle Plattformen eine klare Semantik darüber haben, was das bedeutet. Ihre Umschreibung funktioniert gut in "traditionellen" Go-Programmen, die auf einem vollständigen Betriebssystem laufen - aber sobald Sie Mikrocontroller-Firmware oder auch nur WebAssembly schreiben, ist nicht ganz klar, was os.Exit(1) bedeuten würde. Derzeit ist os.Exit ein Bibliotheksaufruf, daher steht es Go-Implementierungen frei, ihn einfach nicht bereitzustellen. Die Form von main ist jedoch ein Sprachproblem.

Eine Frage zum Vorschlag, die wahrscheinlich am besten mit "Nein" beantwortet werden kann: Wie interagiert try mit variadischen Argumenten? Es ist der erste Fall einer variadischen (ish) Funktion, die ihre variadische Funktion nicht im letzten Argument hat. Ist das erlaubt:

var e []error
try(e...)

Abgesehen davon, warum du das jemals tun würdest. Ich vermute, die Antwort ist "nein" (ansonsten lautet die Fortsetzung "was ist, wenn die Länge des erweiterten Slice 0 ist). Ich bringe das nur zur Sprache, damit es bei der Formulierung der Spezifikation berücksichtigt werden kann.

• Einige der größten Features von go sind, dass aktuelle Builtins einen klaren Kontrollfluss gewährleisten, die Fehlerbehandlung explizit ist und gefördert wird und Entwickler dringend davon abgehalten werden, „magischen“ Code zu schreiben. Der try -Vorschlag steht nicht im Einklang mit diesen Grundprinzipien, da er die Kurzschrift auf Kosten der Kontrollfluss-Lesbarkeit fördert.
• Wenn dieser Vorschlag angenommen wird, sollten Sie vielleicht erwägen, das eingebaute try statt einer Funktion zu einer Anweisung zu machen. Dann ist es konsistenter mit anderen Kontrollflussanweisungen wie if . Zusätzlich verbessert das Entfernen der verschachtelten Klammern die Lesbarkeit geringfügig.
• Nochmals, wenn der Vorschlag angenommen wird, implementieren Sie ihn vielleicht, ohne defer oder ähnliches zu verwenden. Es kann bereits nicht in reinem Go implementiert werden (wie von anderen betont), daher kann es auch eine effizientere Implementierung unter der Haube verwenden.

Ich sehe dabei zwei Probleme:

1. Es fügt eine Menge Code in Funktionen ein. Das fügt eine Menge zusätzlicher kognitiver Belastung hinzu, wenn Sie versuchen, den Code in Ihrem Kopf zu analysieren.

1. Es gibt uns Stellen, an denen der Code aus der Mitte einer Anweisung aussteigen kann.

Nummer 2 finde ich viel schlimmer. Alle Beispiele hier sind einfache Aufrufe, die einen Fehler zurückgeben, aber viel heimtückischer ist Folgendes:

func doit(abc string) error {
    a := fmt.Sprintf("value of something: %s\n", try(getValue(abc)))
    log.Println(a)
    return nil
}

Dieser Code kann mitten in diesem sprintf beendet werden, und es wird SUPER einfach sein, diese Tatsache zu übersehen.

Meine Stimme ist nein. Go-Code wird dadurch nicht besser. Das Lesen wird dadurch nicht einfacher. Robuster wird es dadurch nicht.

Ich habe es bereits gesagt, und dieser Vorschlag veranschaulicht es - ich glaube, dass 90% der Beschwerden über Go lauten: "Ich möchte keine if-Anweisung oder Schleife schreiben" . Dies entfernt einige sehr einfache if-Anweisungen, erhöht jedoch die kognitive Belastung und macht es einfach, Austrittspunkte für eine Funktion zu übersehen.

Ich möchte nur darauf hinweisen, dass Sie dies im Wesentlichen nicht verwenden konnten und es für neue Benutzer oder beim Unterrichten verwirrend sein könnte. Offensichtlich gilt dies für jede Funktion, die keinen Fehler zurückgibt, aber ich denke, main ist etwas Besonderes, da es in vielen Beispielen vorkommt.

func main() {
    f := try(os.Open("foo.txt"))
    defer f.Close()
}

Ich bin mir nicht sicher, ob es auch akzeptabel wäre, in Main Panik zu versuchen.

Außerdem wäre es in Tests ( func TestFoo(t* testing.T) ) nicht besonders nützlich, was unglücklich ist :(

Das Problem, das ich damit habe, ist, dass davon ausgegangen wird, dass Sie den Fehler immer nur zurückgeben möchten, wenn er auftritt. Wenn Sie dem Fehler möglicherweise Kontext hinzufügen und ihn zurückgeben möchten, oder wenn Sie sich einfach anders verhalten möchten, wenn ein Fehler auftritt. Vielleicht hängt das von der Art des zurückgegebenen Fehlers ab.

Ich würde so etwas wie ein Try/Catch bevorzugen, wie es aussehen könnte

Angenommen, foo() ist definiert als

func foo() (int, error) {}

Das könntest du dann machen

n := try(foo()) {
    case FirstError:
        // do something based on FirstError
    case OtherError:
        // do something based on OtherError
    default:
        // default behavior for any other error
}

Was übersetzt bedeutet

n, err := foo()
if errors.Is(err, FirstError) {
    // do something based on FirstError
if errors.Is(err, OtherError) {
    // do something based on OtherError
} else {
    // default behavior for any other error
}

Für mich ist die Fehlerbehandlung einer der wichtigsten Teile einer Codebasis.
Bereits zu viel Go-Code ist if err != nil { return err } , der einen Fehler aus der Tiefe des Stacks zurückgibt, ohne zusätzlichen Kontext hinzuzufügen, oder sogar (möglicherweise) noch schlimmer, wenn Kontext hinzugefügt wird, indem der zugrunde liegende Fehler mit fmt.Errorf Wrapping maskiert wird.

Die Bereitstellung eines neuen Schlüsselworts, das eine Art Magie ist und nichts anderes tut, als if err != nil { return err } zu ersetzen, scheint ein gefährlicher Weg zu sein.
Jetzt wird der gesamte Code einfach in einen Aufruf eingeschlossen, um es zu versuchen. Dies ist etwas in Ordnung (obwohl die Lesbarkeit scheiße ist) für Code, der sich nur mit Fehlern im Paket befasst, wie zum Beispiel:

func foo() error {
  /// stuff
  try(bar())
  // more stuff
}

Aber ich würde argumentieren, dass das gegebene Beispiel wirklich schrecklich ist und den Aufrufer im Grunde versucht, einen Fehler zu verstehen, der wirklich tief im Stapel ist, ähnlich wie bei der Behandlung von Ausnahmen.
Natürlich ist es Sache des Entwicklers, hier das Richtige zu tun, aber es gibt dem Entwickler eine großartige Möglichkeit, sich nicht um seine Fehler zu kümmern, vielleicht mit einem „Wir beheben das später“ (und wir alle wissen, wie das geht ).

Ich wünschte, wir würden das Thema aus einer anderen Perspektive betrachten als * „wie können wir Wiederholungen reduzieren“ und mehr über „wie können wir die (richtige) Fehlerbehandlung einfacher und Entwickler produktiver machen“.
Wir sollten darüber nachdenken, wie sich dies auf den laufenden Produktionscode auswirkt.

*Hinweis: Dies reduziert die Wiederholung nicht wirklich, sondern ändert nur, was wiederholt wird, während der Code weniger lesbar wird, da alles in try() eingeschlossen ist.

Ein letzter Punkt: Das Lesen des Vorschlags scheint zunächst nett zu sein, dann fängt man an, sich auf alle Fallstricke einzulassen (zumindest die aufgelisteten) und es ist nur wie "ok, ja, das ist zu viel".

Mir ist klar, dass vieles davon subjektiv ist, aber es ist etwas, das mir wichtig ist. Diese Semantik ist unglaublich wichtig.
Was ich sehen möchte, ist eine Möglichkeit, das Schreiben und Verwalten von Code auf Produktionsebene zu vereinfachen, sodass Sie Fehler auch für Code auf POC-/Demo-Ebene "richtig" machen können.

Da der Fehlerkontext ein wiederkehrendes Thema zu sein scheint ...

Hypothese: Die meisten Go-Funktionen geben (T, error) zurück, im Gegensatz zu (T1, T2, T3, error)

Was wäre, wenn wir try nicht als try(T1, T2, T3, error) (T1, T2, T3) definieren, sondern als
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ? (Dies ist eine Annäherung)

Das heißt, dass die syntaktische Struktur eines try -Aufrufs immer ein erstes Argument ist, das ein Ausdruck ist, der mehrere Werte zurückgibt, von denen der letzte ein Fehler ist.

Dann öffnet dies ähnlich wie make die Tür zu einer 2-Argument-Form des Aufrufs, wobei das zweite Argument der Kontext des Versuchs ist (z. B. eine feste Zeichenfolge, eine Zeichenfolge mit einem %v , eine Funktion, die ein Fehlerargument akzeptiert und einen anderen Fehler zurückgibt usw.)

Dies ermöglicht immer noch das Verketten für den Fall (T, error) , aber Sie können nicht mehr mehrere Rücksendungen verketten, was meiner Meinung nach normalerweise nicht erforderlich ist.

@ cpuguy83 Wenn Sie den Vorschlag lesen, sehen Sie, dass nichts Sie daran hindert, den Fehler zu umschließen. Tatsächlich gibt es mehrere Möglichkeiten, dies zu tun, während Sie immer noch try verwenden. Viele Leute scheinen das aus irgendeinem Grund anzunehmen.

if err != nil { return err } ist genauso wie "wir werden das später beheben" wie try , außer dass es beim Prototyping lästiger ist.

Ich weiß nicht, wie Dinge, die sich in Klammern befinden, weniger lesbar sind als Funktionsschritte, die alle vier Zeilen der Textbausteine ​​sind.

Es wäre nett, wenn Sie auf einige dieser besonderen "Fallstricke" hinweisen würden, die Sie störten, da das das Thema ist.

Die Lesbarkeit scheint ein Problem zu sein, aber was ist mit go fmt, das try() präsentiert, damit es auffällt, so etwas wie:

f := try(
    os.Open("file.txt")
)

@MrTravisB

Das Problem, das ich damit habe, ist, dass davon ausgegangen wird, dass Sie den Fehler immer nur zurückgeben möchten, wenn er auftritt.

Ich bin nicht einverstanden. Es wird davon ausgegangen, dass Sie dies oft genug tun möchten, um eine Abkürzung dafür zu rechtfertigen. Wenn Sie dies nicht tun, steht es der einfachen Behandlung von Fehlern nicht im Wege.

Wenn Sie dem Fehler möglicherweise Kontext hinzufügen und ihn zurückgeben möchten, oder wenn Sie sich einfach anders verhalten möchten, wenn ein Fehler auftritt.

Der Vorschlag beschreibt ein Muster zum Hinzufügen von blockweitem Kontext zu Fehlern. @josharian wies darauf hin, dass die Beispiele jedoch einen Fehler enthalten und nicht klar ist, wie er am besten vermieden werden kann. Ich habe ein paar Beispiele geschrieben, wie man damit umgehen kann.

Für einen spezifischeren Fehlerkontext macht try wieder etwas, und wenn Sie das nicht wollen, verwenden Sie nicht try .

@boomlinde Genau mein Punkt. Dieser Vorschlag versucht, einen einzelnen Anwendungsfall zu lösen, anstatt ein Werkzeug bereitzustellen, um das größere Problem der Fehlerbehandlung zu lösen. Ich denke, die grundlegende Frage, ob genau das, was Sie darauf hingewiesen haben.

Es wird davon ausgegangen, dass Sie dies oft genug tun möchten, um eine Abkürzung dafür zu rechtfertigen.

Meiner Meinung nach und Erfahrung ist dieser Anwendungsfall eine kleine Minderheit und rechtfertigt keine Kurzschreibweise.

Außerdem hat der Ansatz, defer zur Behandlung von Fehlern zu verwenden, Probleme, da er davon ausgeht, dass Sie alle möglichen Fehler gleich behandeln möchten. defer Kontoauszüge können nicht storniert werden.

defer fmt.HandleErrorf(&err, “foobar”)

n := try(foo())

x : try(foo2())

Was ist, wenn ich eine andere Fehlerbehandlung für Fehler haben möchte, die möglicherweise von foo() im Vergleich zu foo2() zurückgegeben werden?

@MrTravisB

Was ist, wenn ich eine andere Fehlerbehandlung für Fehler haben möchte, die möglicherweise von foo() vs. foo2() zurückgegeben werden?

Dann benutzt du etwas anderes. Das ist der Punkt, den @boomlinde machen wollte.

Vielleicht sehen Sie diesen Anwendungsfall persönlich nicht oft, aber viele Leute tun dies, und das Hinzufügen try betrifft Sie nicht wirklich. Je seltener der Anwendungsfall für Sie ist, desto weniger betrifft es Sie, dass try hinzugefügt wird.

@qrpnxz

f := try(os.Open("/foo"))
data := try(ioutil.ReadAll(f))
try(send(data))

(Ja, ich verstehe, dass es ReadFile gibt und dass dieses spezielle Beispiel nicht der beste Weg ist, Daten irgendwohin zu kopieren, nicht der Punkt)

Dies erfordert mehr Leseaufwand, da Sie die Inline des Versuchs analysieren müssen. Die Anwendungslogik wird in einem weiteren Aufruf zusammengefasst.
Ich würde auch argumentieren, dass ein defer Fehlerbehandler hier nicht gut wäre, außer den Fehler einfach in eine neue Nachricht einzuschließen ... was nett ist, aber es gibt mehr beim Umgang mit Fehlern, als es einfach zu machen Mensch zu lesen, was passiert ist.

Zumindest in Rust ist der Operator ein Postfix ( ? an das Ende eines Aufrufs angehängt), was keine zusätzliche Belastung darstellt, um die eigentliche Logik herauszufinden.

Ausdrucksbasierte Flusskontrolle

panic kann eine weitere Flusssteuerungsfunktion sein, aber sie gibt keinen Wert zurück, was sie effektiv zu einer Anweisung macht. Vergleichen Sie dies mit try , was ein Ausdruck ist und überall vorkommen kann.

recover hat einen Wert und wirkt sich auf die Flusssteuerung aus, muss aber in einer defer -Anweisung vorkommen. Diese defer s sind typischerweise Funktionsliterale, recover wird immer nur einmal aufgerufen, daher tritt recover effektiv auch als Anweisung auf. Vergleichen Sie dies erneut mit try , das überall auftreten kann.

Ich denke, diese Punkte bedeuten, dass try es erheblich schwieriger macht, dem Kontrollfluss auf eine Weise zu folgen, die wir zuvor nicht hatten, wie bereits erwähnt wurde, aber ich habe den Unterschied zwischen Anweisungen und Ausdrücken nicht gesehen wies darauf hin.

Noch ein Vorschlag

Erlauben Sie Aussagen wie

if err != nil {
    return nil, 0, err
}

auf einer Zeile mit gofmt formatiert werden, wenn der Block nur eine return -Anweisung enthält und diese Anweisung keine Zeilenumbrüche enthält. Zum Beispiel:

if err != nil { return nil, 0, err }

Begründung

• Es erfordert keine Sprachänderungen
• Die Formatierungsregel ist einfach und klar
• Die Regel kann so gestaltet werden, dass sie aktiviert wird, wobei gofmt Zeilenumbrüche behält, wenn sie bereits vorhanden sind (wie Strukturliterale). Opt-in ermöglicht es dem Autor auch, eine gewisse Fehlerbehandlung hervorzuheben
• Wenn es nicht aktiviert ist, kann der Code mit einem Aufruf von gofmt automatisch auf den neuen Stil portiert werden
• Es ist nur für return -Anweisungen, also wird es nicht unnötigerweise für Golf-Code missbraucht
• Interagiert gut mit Kommentaren, die beschreiben, warum einige Fehler auftreten können und warum sie zurückgegeben werden. Die Verwendung vieler verschachtelter try -Ausdrücke handhabt dies schlecht
• Es reduziert den vertikalen Raum der Fehlerbehandlung um 66 %
• Kein ausdrucksbasierter Kontrollfluss
• Code wird viel häufiger gelesen als geschrieben, daher sollte er für den Leser optimiert werden. Sich wiederholender Code, der weniger Platz einnimmt, ist für den Leser hilfreich, während try sich mehr in Richtung des Schreibers neigt
• Die Leute haben bereits try vorgeschlagen, die auf mehreren Linien existieren. Zum Beispiel dieser Kommentar oder dieser Kommentar , der einen Stil einführt, wie

f, err := os.Open(file)
try(maybeWrap(err))

• Der Stil „in eigener Zeile versuchen“ beseitigt jegliche Zweideutigkeit darüber, welcher err -Wert zurückgegeben wird. Daher vermute ich, dass dieses Formular häufig verwendet wird. Das Zulassen eines linierten if-Blocks ist fast dasselbe, außer dass es auch explizit gibt, was die Rückgabewerte sind
• Es fördert nicht die Verwendung benannter Rücksendungen oder unklarer defer -basierter Verpackungen. Beides erhöht die Hürde für Verpackungsfehler, und ersteres kann godoc Änderungen erfordern
• Es muss nicht diskutiert werden, wann try im Vergleich zur herkömmlichen Fehlerbehandlung verwendet werden sollte
• Schließt nicht aus, in Zukunft try oder etwas anderes zu tun. Die Änderung kann auch dann positiv sein, wenn try akzeptiert wird
• Keine negative Interaktion mit der testing -Bibliothek oder main -Funktionen. In der Tat, wenn der Vorschlag jede einzeilige Anweisung statt nur Rückgaben zulässt, kann dies die Verwendung von zusicherungsbasierten Bibliotheken reduzieren. Erwägen

value, err := something()
if err != nil { t.Fatal(err) }

• Keine negative Wechselwirkung mit der Prüfung auf bestimmte Fehler. Erwägen

n, err := src.Read(buf)
if err == io.EOF { return nil }
else if err != nil { return err }

Zusammenfassend lässt sich sagen, dass dieser Vorschlag geringe Kosten verursacht, optional gestaltet werden kann, keine weiteren Änderungen ausschließt, da er nur stilistisch ist, und den Aufwand für das Lesen von ausführlichem Fehlerbehandlungscode verringert, während alles explizit bleibt. Ich denke, es sollte zumindest als erster Schritt betrachtet werden, bevor man mit try All-in geht.

Von https://github.com/golang/go/issues/32437#issuecomment -498941435

Mit Versuch

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        try(dbfile.RunMigrations(db, dbMigrations))
        t := &Thing{
                thingy:  thingy,
                scanner: try(newScanner(thingy, db, client)),
        }
        t.initOtherThing()
        return t, nil
}

Mit diesem

func NewThing(thingy *foo.Thingy, db *sql.DB, client pb.Client) (*Thing, error) {
        err := dbfile.RunMigrations(db, dbMigrations))
        if err != nil { return nil, fmt.Errorf("running migrations: %v", err) }

        t := &Thing{thingy: thingy}
        t.scanner, err = newScanner(thingy, db, client)
        if err != nil { return nil, fmt.Errorf("creating scanner: %v", err) }

        t.initOtherThing()
        return t, nil
}

Es ist wettbewerbsfähig in der Platznutzung und ermöglicht dennoch das Hinzufügen von Kontext zu Fehlern.

Von https://github.com/golang/go/issues/32437#issuecomment -499007288

Mit Versuch

func (c *Config) Build() error {
    pkgPath := try(c.load())
    b := bytes.NewBuffer(nil)
    try(emplates.ExecuteTemplate(b, "main", c))
    buf := try(format.Source(b.Bytes()))
    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644))
    // ...
}

Mit diesem

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

Der ursprüngliche Kommentar verwendete ein hypothetisches tryf , um die Formatierung anzuhängen, die entfernt wurde. Es ist unklar, wie man alle unterschiedlichen Kontexte am besten hinzufügt, und vielleicht wäre try nicht einmal anwendbar.

@cpuguy83
Für mich ist es besser lesbar mit try . In diesem Beispiel lese ich "Datei öffnen, alle Bytes lesen, Daten senden". Bei normaler Fehlerbehandlung würde ich lesen: "Datei öffnen, prüfen, ob ein Fehler aufgetreten ist, die Fehlerbehandlung tut dies, dann alle Bytes lesen, jetzt prüfen, ob etwas passiert ist ..." Ich weiß, dass Sie das err != nil können try einfach einfacher, denn wenn ich es sehe, kenne ich das Verhalten sofort: gibt zurück, wenn err != nil. Wenn Sie einen Zweig haben, muss ich sehen, was er tut. Es könnte alles tun.

Ich würde auch argumentieren, dass ein Defer-Error-Handler hier nicht gut wäre, außer um den Fehler einfach mit einer neuen Nachricht zu umschließen

Ich bin sicher, es gibt andere Dinge, die Sie in der Zurückstellung tun können, aber egal, try ist sowieso für den einfachen allgemeinen Fall. Immer wenn Sie etwas mehr tun möchten, gibt es immer die gute alte Go-Fehlerbehandlung. Das geht nicht weg.

@zeebo Ja , das gefällt mir.
Der Artikel von @kungfusheep verwendete eine solche einzeilige Fehlerprüfung, und ich war aufgeregt, sie auszuprobieren. Dann, sobald ich speichere, hat gofmt es in drei Zeilen erweitert, was traurig war. Viele Funktionen in der stdlib sind so in einer Zeile definiert, daher hat es mich überrascht, dass gofmt das erweitern würde.

@qrpnxz

Ich lese zufällig viel Go-Code. Eines der besten Dinge an der Sprache ist die Leichtigkeit, die sich daraus ergibt, dass der meiste Code einem bestimmten Stil folgt (danke, gofmt).
Ich möchte keinen Haufen Code lesen, der in try(f()) verpackt ist.
Das bedeutet, dass es entweder zu Abweichungen im Code-Stil/zur Code-Praxis oder zu Linters wie „oh, du hättest hier try() verwenden sollen“ kommen wird (was ich wiederum nicht einmal mag, was der Punkt ist, an dem ich und andere kommentieren zu diesem Vorschlag).

Es ist objektiv nicht besser als if err != nil { return err } , nur weniger zu tippen.

Eine letzte Sache:

Wenn Sie den Vorschlag lesen, werden Sie sehen, dass nichts Sie daran hindert

Können wir diese Sprache bitte unterlassen? Natürlich habe ich den Vorschlag gelesen. Es ist einfach so, dass ich es gestern Abend gelesen und dann heute Morgen kommentiert habe, nachdem ich darüber nachgedacht habe, und nicht die Einzelheiten meiner Absicht erklärt habe.
Das ist ein unglaublich feindseliger Ton.

@cpuguy83
Mein böser CPU-Typ. So habe ich das nicht gemeint.

Und ich denke, Sie müssen darauf hinweisen, dass Code, der try verwendet, ziemlich anders aussieht als Code, der dies nicht tut, also kann ich mir vorstellen, dass dies die Erfahrung beim Parsen dieses Codes beeinflussen würde, aber ich kann dem nicht ganz zustimmen bedeutet in diesem Fall schlimmer, obwohl ich verstehe, dass Sie es persönlich nicht mögen, genauso wie ich es persönlich mag. Viele Dinge in Go sind so. Was Linters Ihnen sagen, ist eine ganz andere Sache, denke ich.

Klar ist es objektiv nicht besser. Ich drückte aus, dass es für mich auf diese Weise besser lesbar war. Ich habe das vorsichtig formuliert.

Nochmals Entschuldigung, dass ich mich so anhöre. Obwohl dies ein Argument ist, wollte ich Sie nicht verärgern.

https://github.com/golang/go/issues/32437#issuecomment -498908380

Niemand wird Sie dazu zwingen, es zu versuchen.

Ich ignoriere die Geschmeidigkeit, ich denke, das ist eine ziemlich handgewellte Art, eine Designkritik abzutun.

Sicher, ich muss es nicht benutzen. Aber jeder, mit dem ich Code schreibe, könnte ihn verwenden und mich dazu zwingen, zu versuchen, try(try(try(to()).parse().this)).easily()) zu entschlüsseln. Es ist wie gesagt

Niemand wird Sie dazu zwingen, die leere Schnittstelle zu verwenden{}.

Wie auch immer, Go ist ziemlich streng in Bezug auf Einfachheit: gofmt lässt den gesamten Code gleich aussehen. Der glückliche Pfad bleibt links und alles, was teuer oder überraschend sein könnte, ist explizit . try wie vorgeschlagen ist eine 180-Grad-Wendung davon. Einfachheit != prägnant.

Zumindest try sollte ein Schlüsselwort mit lvalues ​​sein.

Es ist _objektiv_ nicht besser als if err != nil { return err } , nur weniger zu tippen.

Es gibt einen objektiven Unterschied zwischen den beiden: try(Foo()) ist ein Ausdruck. Für einige ist dieser Unterschied ein Nachteil (die try(strconv.Atoi(x))+try(strconv.Atoi(y)) -Kritik). Für andere ist dieser Unterschied aus dem gleichen Grund ein Vorteil. Immer noch nicht objektiv besser oder schlechter - aber ich denke auch nicht, dass der Unterschied unter den Teppich gekehrt werden sollte und die Behauptung, es sei "nur weniger zu tippen", wird dem Vorschlag nicht gerecht.

@elagergren-spideroak schwer zu sagen, dass try ärgerlich ist, in einem Atemzug zu sehen und dann zu sagen, dass es im nächsten nicht explizit ist. Du musst dir einen aussuchen.

Es ist üblich, dass Funktionsargumente zuerst in temporäre Variablen geschrieben werden. Ich bin mir sicher, dass es häufiger zu sehen wäre

this := try(to()).parse().this
that := try(this.easily())

als dein Beispiel.

try Nichtstun ist der glückliche Weg, das sieht also wie erwartet aus. Auf dem unglücklichen Weg kehrt es nur zurück. Zu sehen, dass es try gibt, reicht aus, um diese Informationen zu sammeln. Es ist auch nicht teuer, von einer Funktion zurückzukehren, also glaube ich nicht, dass try nach dieser Beschreibung eine 180 macht

@josharian In Bezug auf Ihren Kommentar in https://github.com/golang/go/issues/32437#issuecomment -498941854 glaube ich nicht, dass hier ein früher Bewertungsfehler vorliegt.

defer fmt.HandleErrorf(&err, „foobar: %v“, err)

Der unveränderte Wert von err wird an HandleErrorf übergeben, und ein Zeiger auf err wird übergeben. Wir prüfen, ob err nil ist (mit dem Zeiger). Wenn nicht, formatieren wir die Zeichenfolge mit dem unveränderten Wert von err . Dann setzen wir err mit dem Zeiger auf den formatierten Fehlerwert.

@Merovius Der Vorschlag ist jedoch wirklich nur ein Syntax-Zucker-Makro, also wird es am Ende darum gehen, was die Leute denken, dass es schöner aussieht oder am wenigsten Probleme verursacht. Wenn Sie das nicht glauben, erklären Sie es mir bitte. Deshalb bin ich persönlich dafür. Es ist eine nette Ergänzung, ohne irgendwelche Schlüsselwörter aus meiner Sicht hinzuzufügen.

@ianlancetaylor , ich denke, @josharian hat Recht: Der „unmodifizierte“ Wert von err ist der Wert zu dem Zeitpunkt, zu dem defer auf den Stack geschoben wird, nicht der (vermutlich beabsichtigte) Wert von err gesetzt durch try vor der Rückkehr.

Das andere Problem, das ich mit try habe, ist, dass es für die Leute so viel einfacher ist, mehr und mehr Logik in eine einzige Zeile zu packen. Das ist mein größtes Problem mit den meisten anderen Sprachen, dass sie es wirklich einfach machen, etwa 5 Ausdrücke in eine einzige Zeile zu schreiben, und das möchte ich nicht einfach so lassen.

this := try(to()).parse().this
that := try(this.easily())

^^ Auch das ist geradezu schrecklich. In der ersten Zeile muss ich hin und her springen, um in meinem Kopf Paren-Matching zu machen. Schon die zweite Zeile, die eigentlich ganz einfach ist... ist wirklich schwer zu lesen.
Verschachtelte Funktionen sind schwer zu lesen.

parser, err := to()
if err != nil {
    return err
}
this := parser.parse().this
that, err := this.easily()
if err != nil {
    return err
}

^^ Das ist meiner Meinung nach so viel einfacher und besser. Es ist super einfach und klar. Ja, es sind viel mehr Codezeilen, das ist mir egal. Es ist sehr offensichtlich.

@bcmills @josharian Ah, natürlich, danke. So müsste es sein

defer func() { fmt.HandleErrorf(&err, “foobar: %v”, err) }()

Nicht sehr nett. Vielleicht sollte fmt.HandleErrorf doch implizit den Fehlerwert als letztes Argument übergeben.

Diese Ausgabe hat sehr schnell viele Kommentare erhalten, und viele von ihnen scheinen mir Kommentare zu wiederholen, die bereits gemacht wurden. Natürlich können Sie gerne einen Kommentar abgeben, aber ich möchte freundlich vorschlagen, dass Sie, wenn Sie einen bereits gemachten Punkt wiederholen möchten, dies tun, indem Sie die Emojis von GitHub verwenden, anstatt den Punkt zu wiederholen. Danke.

@ianlancetaylor Wenn fmt.HandleErrorf err als erstes Argument nach dem Format sendet, wird die Implementierung schöner und der Benutzer kann immer mit %[1]v darauf verweisen.

@natefinch Absolut einverstanden.

Ich frage mich, ob ein Ansatz im Roststil schmackhafter wäre?
Beachten Sie, dass dies kein Vorschlag ist, nur darüber nachzudenken ...

this := to()?.parse().this
that := this.easily()?

Am Ende denke ich, dass dies schöner ist, aber (könnte auch ein ! oder etwas anderes verwenden ...), aber das Problem der Fehlerbehandlung wird immer noch nicht gut behoben.

Rost hat natürlich auch try() , ziemlich genau so, aber... der andere Roststil.

Es ist _objektiv_ nicht besser als if err != nil { return err } , nur weniger zu tippen.

Es gibt einen objektiven Unterschied zwischen den beiden: try(Foo()) ist ein Ausdruck. Für einige ist dieser Unterschied ein Nachteil (die try(strconv.Atoi(x))+try(strconv.Atoi(y)) -Kritik). Für andere ist dieser Unterschied aus dem gleichen Grund ein Vorteil. Immer noch nicht objektiv besser oder schlechter - aber ich denke auch nicht, dass der Unterschied unter den Teppich gekehrt werden sollte und die Behauptung, es sei "nur weniger zu tippen", wird dem Vorschlag nicht gerecht.

Das ist einer der Hauptgründe, warum ich diese Syntax mag; Dadurch kann ich eine Fehler zurückgebende Funktion als Teil eines größeren Ausdrucks verwenden, ohne alle Zwischenergebnisse benennen zu müssen. In manchen Situationen ist es einfach, sie zu benennen, aber in anderen gibt es keinen besonders aussagekräftigen oder nicht überflüssigen Namen, den ich ihnen geben könnte. In diesem Fall würde ich ihnen lieber überhaupt keinen Namen geben.

@MrTravisB

Genau mein Standpunkt. Dieser Vorschlag versucht, einen einzelnen Anwendungsfall zu lösen, anstatt ein Werkzeug bereitzustellen, um das größere Problem der Fehlerbehandlung zu lösen. Ich denke, die grundlegende Frage, ob genau das, was Sie darauf hingewiesen haben.

Was genau habe ich gesagt, das ist genau Ihr Punkt? Mir scheint eher, dass Sie meinen Punkt grundlegend missverstanden haben, wenn Sie glauben, dass wir uns einig sind.

Meiner Meinung nach und Erfahrung ist dieser Anwendungsfall eine kleine Minderheit und rechtfertigt keine Kurzschreibweise.

In der Go-Quelle gibt es Tausende von Fällen, die von try standardmäßig behandelt werden könnten, selbst wenn es keine Möglichkeit gäbe, Fehlern Kontext hinzuzufügen. Wenn geringfügig, ist es immer noch ein häufiger Grund für Beschwerden.

Außerdem hat der Ansatz, Fehler mit defer zu behandeln, Probleme, da davon ausgegangen wird, dass Sie alle möglichen Fehler gleich behandeln möchten. defer-Anweisungen können nicht storniert werden.

In ähnlicher Weise geht der Ansatz, + zur Behandlung von Arithmetik zu verwenden, davon aus, dass Sie nicht subtrahieren möchten, also tun Sie es nicht, wenn Sie es nicht tun. Die interessante Frage ist, ob der blockweite Fehlerkontext zumindest ein gemeinsames Muster darstellt.

Was ist, wenn ich eine andere Fehlerbehandlung für Fehler haben möchte, die möglicherweise von foo() vs. foo2() zurückgegeben werden?

Auch hier verwenden Sie nicht try . Dann gewinnen Sie nichts von try , aber Sie verlieren auch nichts.

@cpuguy83

Ich frage mich, ob ein Ansatz im Roststil schmackhafter wäre?

Dagegen spricht der Vorschlag.

An diesem Punkt denke ich, dass es besser lesbar ist, try{}catch{} zu haben :upside_down_face:

1. Benannte Importe zu verwenden, um defer -Eckfälle zu umgehen, ist nicht nur schrecklich für Dinge wie godoc, sondern vor allem sehr fehleranfällig. Es ist mir egal, ich kann das Ganze mit weiteren func() umwickeln, um das Problem zu umgehen, es sind nur mehr Dinge, die ich beachten muss, ich denke, es fördert eine "schlechte Praxis".

2. Niemand wird Sie dazu zwingen, es zu versuchen.

   Das bedeutet nicht, dass es eine gute Lösung ist, ich weise darauf hin, dass die aktuelle Idee einen Fehler im Design hat, und ich bitte darum, dass dies auf eine weniger fehleranfällige Weise angegangen wird.

3. Ich denke, Beispiele wie try(try(try(to()).parse().this)).easily()) sind unrealistisch, dies könnte bereits mit anderen Funktionen geschehen, und ich denke, es wäre fair, wenn diejenigen, die den Code überprüfen, eine Aufteilung verlangen würden.

4. Was ist, wenn ich 3 Stellen habe, an denen ein Fehler auftreten kann, und ich jede Stelle separat umschließen möchte? try() macht dies sehr schwierig, tatsächlich entmutigt try() angesichts der Schwierigkeit bereits Verpackungsfehler, aber hier ist ein Beispiel dafür, was ich meine:

   func before() error {
     x, err := foo()
     if err != nil {
       wrap(err, "error on foo")
     }
     y, err := bar(x)
     if err != nil {
       wrapf(err, "error on bar with x=%v", x)
     }
     fmt.Println(y)
     return nil
   }
   
   func after() (err error) {
     defer fmt.HandleErrorf(&err, "something failed but I don't know where: %v", err)
     x := try(foo())
     y := try(bar(x))
     fmt.Println(y)
     return nil
   }
   

5. Auch hier verwenden Sie nicht try . Dann gewinnen Sie nichts von try , aber Sie verlieren auch nichts.

   Nehmen wir an, es ist eine gute Praxis, Fehler mit nützlichem Kontext zu umschließen, try() würde als schlechte Praxis betrachtet werden, weil es keinen Kontext hinzufügt. Dies bedeutet, dass try() eine Funktion ist, die niemand verwenden möchte, und zu einer Funktion wird, die so selten verwendet wird, dass sie möglicherweise genauso gut nicht existiert hat.

   Anstatt nur zu sagen "Nun, wenn es dir nicht gefällt, benutze es nicht und halt die Klappe" (so liest es sich), wäre es meiner Meinung nach besser zu versuchen, das anzusprechen, was viele Benutzer als Fehler betrachten in dem Design. Können wir stattdessen diskutieren, was am vorgeschlagenen Design geändert werden könnte, damit unser Anliegen besser gehandhabt werden kann?

@boomlinde Der Punkt, dem wir zustimmen, ist, dass dieser Vorschlag versucht, einen geringfügigen Anwendungsfall zu lösen, und die Tatsache, dass "wenn Sie es nicht brauchen, verwenden Sie es nicht" das Hauptargument dafür ist, fördert diesen Punkt. Wie @elagergren-spideroak feststellte, funktioniert dieses Argument nicht, denn selbst wenn ich es nicht verwenden möchte, werden andere es tun, was mich dazu zwingt, es zu verwenden. Nach der Logik Ihres Arguments sollte Go auch eine ternäre Aussage haben. Und wenn Sie ternäre Aussagen nicht mögen, verwenden Sie sie nicht.

Haftungsausschluss - Ich denke, Go sollte eine ternäre Aussage haben, aber da Gos Ansatz für Sprachfunktionen darin besteht, keine Funktionen einzuführen, die das Lesen von Code erschweren könnten , sollte dies nicht der Fall sein.

Mir fällt noch etwas ein: Ich sehe viel Kritik aufgrund der Idee, dass try Entwickler dazu ermutigen könnte, sorglos mit Fehlern umzugehen. Aber meiner Meinung nach trifft dies eher auf die aktuelle Sprache zu; Die Textbausteine ​​zur Fehlerbehandlung sind so ärgerlich, dass sie dazu anregen, einige Fehler zu schlucken oder zu ignorieren, um sie zu vermeiden. Zum Beispiel habe ich ein paar Mal so etwas geschrieben:

func exists(filename string) bool {
  _, err := os.Stat(filename)
  return err == nil
}

um if exists(...) { ... } schreiben zu können, obwohl dieser Code einige mögliche Fehler stillschweigend ignoriert. Wenn ich try hätte, würde ich mich wahrscheinlich nicht darum kümmern und einfach (bool, error) zurückgeben.

Da ich hier chaotisch bin, werfe ich die Idee auf, eine zweite eingebaute Funktion namens catch hinzuzufügen, die eine Funktion empfängt, die einen Fehler akzeptiert und einen überschriebenen Fehler zurückgibt, wenn dann ein nachfolgendes catch aufgerufen wird, würde es den Handler überschreiben. zum Beispiel:

func catch(handler func(err error) error) {
  // .. impl ..
}

Nun wird diese eingebaute Funktion auch eine Makro-ähnliche Funktion sein, die den nächsten Fehler behandeln würde, der von try wie folgt zurückgegeben wird:

func wrapf(format string, ...values interface{}) func(err error) error {
  // user defined
  return func(err error) error {
    return fmt.Errorf(format + ": %v", ...append(values, err))
  }
}
func sample() {
  catch(wrapf("something failed in foo"))
  try(foo()) // "something failed in foo: <error>"
  x := try(foo2()) // "something failed in foo: <error>"
  // Subsequent calls for catch overwrite the handler
  catch(wrapf("something failed in bar with x=%v", x))
  try(bar(x)) // "something failed in bar with x=-1: <error>"
}

Das ist nett, weil ich Fehler ohne defer umbrechen kann, was fehleranfällig sein kann, es sei denn, wir verwenden benannte Rückgabewerte oder umbrechen mit einer anderen Funktion, es ist auch nett, weil defer den gleichen Fehlerhandler für hinzufügen würde alle Fehler, auch wenn ich 2 davon anders behandeln möchte. Sie können es auch verwenden, wie Sie es für richtig halten, zum Beispiel:

func foo(a, b string) (int64, error) {
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func withContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, b: %s, err: %v", a, b, err)
  })
  return try(strconv.Atoi(a)) + try(strconv.Atoi(b))
}
func moreExplicitContext(a, b string) (int64, error) {
  catch(func (err error) error {
    return fmt.Errorf("can't parse a: %s, err: %v", a, err)
  })
  x := try(strconv.Atoi(a))
  catch(func (err error) error {
    return fmt.Errorf("can't parse b: %s, err: %v", b, err)
  })
  y := try(strconv.Atoi(b))
  return x + y
}
func withHelperWrapf(a, b string) (int64, error) {
  catch(wrapf("can't parse a: %s", a))
  x := try(strconv.Atoi(a))
  catch(wrapf("can't parse b: %s", b))
  y := try(strconv.Atoi(b))
  return x + y
}
func before(a, b string) (int64, error) {
  x, err := strconv.Atoi(a)
  if err != nil {
    return 0,  fmt.Errorf("can't parse a: %s, err: %v", a, err)
  }
  y, err := strconv.Atoi(b)
  if err != nil {
    return 0,  fmt.Errorf("can't parse b: %s, err: %v", b, err)
  }
  return x + y
}

Und immer noch in der chaotischen Stimmung (um Ihnen zu helfen, sich einzufühlen) Wenn Sie catch nicht mögen, müssen Sie es nicht verwenden.

Nun ... Ich meine den letzten Satz nicht wirklich, aber es fühlt sich an, als wäre er für die Diskussion nicht hilfreich, sehr aggressiv IMO.
Trotzdem, wenn wir diesen Weg gehen, denke ich, dass wir stattdessen genauso gut try{}catch(error err){} haben könnten :stuck_out_tongue:

Siehe auch #27519 - das Fehlermodell #id/catch

Niemand wird Sie dazu zwingen, es zu versuchen.

Ich ignoriere die Geschmeidigkeit, ich denke, das ist eine ziemlich handgewellte Art, eine Designkritik abzutun.

Entschuldigung, Glib war nicht meine Absicht.

Was ich versuche zu sagen, ist, dass try keine 100%ige Lösung sein soll. Es gibt verschiedene Fehlerbehandlungsparadigmen, die von try nicht gut gehandhabt werden. Zum Beispiel, wenn Sie dem Fehler callsite-abhängigen Kontext hinzufügen müssen. Sie können immer auf if err != nil { zurückgreifen, um diese komplizierteren Fälle zu handhaben.

Es ist sicherlich ein gültiges Argument, dass try für verschiedene Instanzen von X nicht mit X umgehen kann. Aber oft bedeutet die Behandlung von Fall X, dass der Mechanismus komplizierter wird. Hier gibt es einen Kompromiss, der einerseits mit X umgeht, aber den Mechanismus für alles andere kompliziert. Was wir alles tun, hängt davon ab, wie verbreitet X ist und wie viel Komplikation es erfordern würde, mit X umzugehen.

Mit "Niemand wird Sie dazu bringen, es zu versuchen" meine ich, dass ich denke, dass das fragliche Beispiel zu den 10% gehört, nicht zu den 90%. Diese Behauptung steht sicherlich zur Debatte, und ich freue mich über Gegenargumente. Aber irgendwann müssen wir irgendwo eine Grenze ziehen und sagen: "Ja, try wird diesen Fall nicht behandeln. Sie müssen die Fehlerbehandlung im alten Stil verwenden. Entschuldigung.".

Es ist nicht so, dass "try diesen speziellen Fall der Fehlerbehandlung nicht behandeln kann", das das Problem ist, sondern "try ermutigt Sie, Ihre Fehler nicht zu umschließen". Die check-handle -Idee zwang Sie dazu, eine return-Anweisung zu schreiben, daher war das Schreiben eines Fehlerumbruchs ziemlich trivial.

Bei diesem Vorschlag müssen Sie eine benannte Rückgabe mit einem defer verwenden, was nicht intuitiv ist und sehr hacky erscheint.

Die check-handle -Idee zwang Sie dazu, eine return-Anweisung zu schreiben, daher war das Schreiben eines Fehlerumbruchs ziemlich trivial.

Das stimmt nicht – im Designentwurf hat jede Funktion, die einen Fehler zurückgibt, einen Standard-Handler , der nur den Fehler zurückgibt.

Aufbauend auf dem schelmischen Punkt von @Goodwine brauchen Sie nicht wirklich separate Funktionen wie HandleErrorf , wenn Sie eine einzelne Brückenfunktion wie haben

func handler(err *error, handle func(error) error) {
  // nil handle is treated as the identity
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

die Sie gerne verwenden würden

defer handler(&err, func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

Sie könnten handler selbst zu einem halbmagischen eingebauten Element wie try machen.

Wenn es magisch ist, könnte es sein erstes Argument implizit nehmen – wodurch es sogar in Funktionen verwendet werden kann, die ihre error -Rückgabe nicht benennen, wodurch einer der weniger glücklichen Aspekte des aktuellen Vorschlags ausgeschaltet und weniger gut gemacht wird pingelig und fehleranfällig, um Fehler zu schmücken. Das reduziert das vorherige Beispiel natürlich nicht wesentlich:

defer handler(func(err error) error {
  if errors.Is(err, io.EOF) {
    return nil
  }
  return fmt.Errorf("oops: %w", err)
})

Wenn es auf diese Weise magisch wäre, müsste es ein Kompilierzeitfehler sein, wenn es irgendwo verwendet würde, außer als Argument für defer . Sie könnten noch einen Schritt weiter gehen und es implizit aufschieben, aber defer handler liest sich ganz gut.

Da es defer verwendet, könnte es seine Funktion handle immer dann aufrufen, wenn ein Nicht-Null-Fehler zurückgegeben wird, was es auch ohne try nützlich macht, da Sie ein hinzufügen könnten

defer handler(wrapErrWithPackageName)

ganz oben bis fmt.Errorf("mypkg: %w", err) alles.

Das gibt Ihnen viele der älteren check / handle Vorschläge, aber es funktioniert natürlich (und explizit) mit defer, während es in den meisten Fällen die Notwendigkeit beseitigt, err explizit zu benennen try ist es ein relativ unkompliziertes Makro, das (glaube ich) vollständig im Frontend implementiert werden könnte.

Das stimmt nicht - im Designentwurf hat jede Funktion, die einen Fehler zurückgibt, einen Standardhandler, der nur den Fehler zurückgibt.

Meine Güte, du hast Recht.

Ich meine, dass ich denke, dass das fragliche Beispiel zu den 10% gehört, nicht zu den 90%. Diese Behauptung steht sicherlich zur Debatte, und ich freue mich über Gegenargumente. Aber irgendwann müssen wir irgendwo eine Grenze ziehen und sagen: "Ja, try wird diesen Fall nicht behandeln. Sie müssen die Fehlerbehandlung im alten Stil verwenden. Entschuldigung.".

Einverstanden, meine Meinung ist, dass diese Linie bei der Prüfung auf EOF oder ähnliches gezogen werden sollte, nicht beim Wickeln. Aber vielleicht wäre dies kein Problem mehr, wenn Fehler mehr Kontext hätten.

Könnte try() Fehler automatisch mit nützlichem Kontext zum Debuggen umbrechen? Wenn beispielsweise xerrors zu errors wird, sollten Fehler etwas haben, das wie ein Stack-Trace aussieht, den try() hinzufügen könnte, oder? Wenn ja, würde das vielleicht reichen 🤔

Wenn die Ziele sind (Lesen von https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md):

• eliminieren Sie die Kesselplatte
• minimale Sprachänderungen
• Abdeckung der „häufigsten Szenarien“
• fügt der Sprache nur sehr wenig Komplexität hinzu

Ich würde den Vorschlag nehmen, ihm einen Winkel zu geben und eine Codemigration in "kleinen Schritten" für all die Milliarden Codezeilen da draußen zuzulassen.

statt wie vorgeschlagen:

func printSum(a, b string) error {
        defer fmt.HandleErrorf(&err, "sum %s %s: %v", a,b, err) 
        x := try(strconv.Atoi(a))
        y := try(strconv.Atoi(b))
        fmt.Println("result:", x + y)
        return nil
}

Wir können:

func printSum(a, b string) error {
        var err ErrHandler{HandleFunc : twoStringsErr("printSum",a,b)} 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

Was würden wir gewinnen?
twoStringsErr kann in printSum oder in einen allgemeinen Handler eingebunden werden, der Fehler erfassen kann (in diesem Fall mit 2 Zeichenfolgenparametern). Zeit
Auf die gleiche Weise kann ich den ErrHandler-Typ wie folgt erweitern:

type ioErrHandler ErrHandler
func (i ErrHandler) Handle() ...{

}

oder

type parseErrHandler ErrHandler
func (p parseErrHandler) Handle() ...{

}

oder

type str2IntErrHandler ErrHandler
func (s str2IntErrHandler) Handle() ...{

}

und verwenden Sie dies rund um meinen Code:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        return nil
}

Die eigentliche Notwendigkeit wäre also, einen Trigger zu entwickeln, wenn err.Error auf nicht null gesetzt ist
Mit dieser Methode können wir auch:

func (s str2IntErrHandler) Handle() bool{
   **return false**
}

Was der aufrufenden Funktion mitteilen würde, fortzufahren, anstatt zurückzukehren

Und verwenden Sie verschiedene Fehlerbehandler in derselben Funktion:

func printSum(a, b string) error {
        var pErr str2IntErrHandler 
        var oErr overflowError 
        x, err.Error := strconv.Atoi(a)
        y,err.Error := strconv.Atoi(b)
        fmt.Println("result:", x + y)
        totalAsByte,oErr := sumBytes(x,y)
        sunAsByte,oErr := subtractBytes(x,y)
        return nil
}

usw.

Gehen Sie die Ziele noch einmal durch

• Boilerplate eliminieren - fertig
• minimale Sprachänderungen - fertig
• Abdeckung "häufigster Szenarien" - mehr als die vorgeschlagene IMO
• fügt der Sprache sehr wenig Komplexität hinzu - sone
  Plus - einfachere Codemigration von

x, err := strconv.Atoi(a)

zu

x, err.Error := strconv.Atoi(a)

und tatsächlich - bessere Lesbarkeit (IMO, wieder)

@guybrand du bist der neueste Anhänger dieses wiederkehrenden Themas (was mir gefällt).

Siehe https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

@guybrand Das scheint ein ganz anderer Vorschlag zu sein; Ich denke, Sie sollten es als eigene Ausgabe einreichen, damit sich diese auf die Diskussion des Vorschlags von @griesemer konzentrieren kann.

@natefinch stimme zu. Ich denke, dies ist eher darauf ausgerichtet, die Erfahrung beim Schreiben von Go zu verbessern, anstatt es für das Lesen zu optimieren. Ich frage mich, ob IDE-Makros oder -Snippets das Problem lösen könnten, ohne dass dies zu einem Merkmal der Sprache wird.

@Guter Wein

Nehmen wir an, es ist eine gute Praxis, Fehler mit nützlichem Kontext zu umschließen, try() würde als schlechte Praxis betrachtet werden, weil es keinen Kontext hinzufügt. Dies bedeutet, dass try() eine Funktion ist, die niemand verwenden möchte, und zu einer Funktion wird, die so selten verwendet wird, dass sie möglicherweise genauso gut nicht existiert hat.

Wie im Vorschlag erwähnt (und anhand eines Beispiels gezeigt), hindert try Sie nicht grundsätzlich daran, Kontext hinzuzufügen. Ich würde sagen, dass die Art und Weise, wie vorgeschlagen wird, Fehlern Kontext hinzuzufügen, völlig orthogonal dazu ist. Dies wird speziell in den FAQ des Vorschlags angesprochen.

Ich erkenne an, dass try nicht nützlich ist, wenn innerhalb einer einzelnen Funktion eine Vielzahl verschiedener Kontexte vorhanden sind, die Sie zu verschiedenen Fehlern aus Funktionsaufrufen hinzufügen möchten. Allerdings glaube ich auch, dass etwas in der Art von HandleErrorf einen großen Anwendungsbereich abdeckt, weil es nicht ungewöhnlich ist, nur funktionsweiten Kontext zu Fehlern hinzuzufügen.

Anstatt nur zu sagen "Nun, wenn es dir nicht gefällt, benutze es nicht und halt die Klappe" (so liest es sich), wäre es meiner Meinung nach besser zu versuchen, das anzusprechen, was viele Benutzer als Fehler betrachten in dem Design.

Wenn es sich so liest entschuldige ich mich. Mein Punkt ist nicht, dass Sie so tun sollten, als ob es nicht existiert, wenn Sie es nicht mögen. Es ist offensichtlich, dass es Fälle gibt, in denen try nutzlos wären und dass Sie es in solchen Fällen nicht verwenden sollten, was meiner Meinung nach für diesen Vorschlag eine gute Balance zwischen KISS und allgemeinem Nutzen bietet. Ich dachte nicht, dass ich in diesem Punkt unklar war.

Danke an alle für das produktive Feedback bisher; das ist sehr informativ.
Hier mein Versuch einer ersten Zusammenfassung, um ein besseres Gefühl für das Feedback zu bekommen. Entschuldigung im Voraus für alle, die ich verpasst oder falsch dargestellt habe; Ich hoffe, dass ich den Gesamteindruck richtig verstanden habe.

0) Auf der positiven Seite haben @rasky , @adg , @eandre , @dpinela und andere ihre Freude über die Code-Vereinfachung ausgedrückt, die try bietet.

1) Die wichtigste Sorge scheint zu sein, dass try keinen guten Fehlerbehandlungsstil fördert, sondern stattdessen den "schnellen Ausstieg" fördert. ( @agnivade , @peterbourgon , @politician , @a8m , @eandre , @prologic , @kungfusheep , @cpuguy und andere haben ihre Besorgnis darüber geäußert.)

2) Viele Leute mögen die Idee eines eingebauten oder der damit verbundenen Funktionssyntax nicht, weil sie ein return verbirgt. Es wäre besser, ein Schlüsselwort zu verwenden. ( @sheerun , @Redundancy , @dolmen , @komuw , @RobertGrantEllis , @elagergren-spideroak). try kann auch leicht übersehen werden (@peterbourgon), besonders weil es in Ausdrücken vorkommen kann, die willkürlich verschachtelt sind. @natefinch ist besorgt, dass try es „zu einfach macht, zu viel in eine Zeile zu packen“, etwas, das wir normalerweise in Go zu vermeiden versuchen. Außerdem ist die IDE-Unterstützung zum Hervorheben try möglicherweise nicht ausreichend (@dominikh); try muss "für sich stehen".

3) Für einige ist der Status Quo expliziter if -Aussagen kein Problem, sie sind damit zufrieden ( @bitfield , @marwan-at-work, @natefinch). Es ist besser, nur einen Weg zu haben, Dinge zu erledigen (@gbbr); und explizite if -Anweisungen sind besser als implizite return -Anweisungen ( @DavexPro , @hmage , @prologic , @natefinch).
In ähnlicher Weise ist @mattn besorgt über die "implizite Bindung" des Fehlerergebnisses an try - die Verbindung ist im Code nicht explizit sichtbar.

4) Die Verwendung try erschwert das Debuggen von Code; Beispielsweise kann es erforderlich sein, einen try -Ausdruck wieder in eine if -Anweisung umzuschreiben, damit Debugging-Anweisungen eingefügt werden können ( @deanveloper , @typeless , @networkimprov , andere).

5) Es gibt einige Bedenken hinsichtlich der Verwendung benannter Rückgaben ( @buchanae , @adg).

Mehrere Personen haben Vorschläge zur Verbesserung oder Änderung des Vorschlags gemacht:

6) Einige haben die Idee einer optionalen Fehlerbehandlungsroutine (@beoran) oder einer Formatzeichenfolge aufgegriffen, die für try ( @unexge , @a8m , @eandre , @gotwarlost) bereitgestellt wird, um eine gute Fehlerbehandlung zu fördern.

7) @pierrec schlug vor, dass gofmt try -Ausdrücke passend formatieren könnte, um sie besser sichtbar zu machen.
Alternativ könnte man vorhandenen Code kompakter machen, indem man gofmt erlaubt, $ if -Anweisungen zu formatieren, die in einer Zeile auf Fehler prüfen (@zeebo).

8) @marwan-at-work argumentiert, dass try die Fehlerbehandlung einfach von if -Anweisungen auf try -Ausdrücke verschiebt. Wenn wir das Problem tatsächlich lösen wollen, sollte Go stattdessen die Fehlerbehandlung "besitzen", indem es sie wirklich implizit macht. Das Ziel sollte sein, die (richtige) Fehlerbehandlung einfacher und Entwickler produktiver zu machen (@cpuguy).

9) Schließlich mögen manche Leute den Namen try ( @beoran , @HiImJC , @dolmen) nicht oder bevorzugen ein Symbol wie ? ( @twisted1919 , @leaxoy , andere) .

Einige Kommentare zu diesem Feedback (entsprechend nummeriert):

0) Danke für das positive Feedback! :-)

1) Es wäre gut, mehr über dieses Anliegen zu erfahren. Der aktuelle Codierungsstil, der if -Anweisungen verwendet, um auf Fehler zu testen, ist so explizit wie möglich. Es ist sehr einfach, auf individueller Basis zusätzliche Informationen zu einem Fehler hinzuzufügen (für jeweils if ). Oft ist es sinnvoll, alle in einer Funktion erkannten Fehler einheitlich zu behandeln, was mit einem defer möglich ist - das ist bereits jetzt möglich. Die Tatsache, dass wir bereits alle Werkzeuge für eine gute Fehlerbehandlung in der Sprache haben, und das Problem, dass ein Handler-Konstrukt nicht orthogonal zu defer ist, hat uns dazu veranlasst, einen neuen Mechanismus wegzulassen, der ausschließlich Fehler vergrößert .

2) Es besteht natürlich die Möglichkeit, anstelle einer eingebauten ein Schlüsselwort oder eine spezielle Syntax zu verwenden. Ein neues Schlüsselwort ist nicht abwärtskompatibel. Ein neuer Betreiber könnte, scheint aber noch weniger sichtbar zu sein. Der detaillierte Vorschlag diskutiert ausführlich die verschiedenen Vor- und Nachteile. Aber vielleicht schätzen wir das falsch ein.

3) Der Grund für diesen Vorschlag ist, dass die Fehlerbehandlung (insbesondere der zugehörige Boilerplate-Code) von der Go-Community als ein wichtiges Problem in Go (neben dem Fehlen von Generika) erwähnt wurde. Dieser Vorschlag befasst sich direkt mit dem Boilerplate-Problem. Es löst nicht mehr als den grundlegendsten Fall, da jeder komplexere Fall besser mit dem behandelt werden kann, was wir bereits haben. Während also eine gute Anzahl von Menschen mit dem Status quo zufrieden ist, gibt es eine (wahrscheinlich) ebenso große Anzahl von Menschen, die einen rationaleren Ansatz wie try lieben würden, wohl wissend, dass dies „nur“ syntethischer Zucker.

4) Der Debugging-Punkt ist ein berechtigtes Anliegen. Wenn zwischen dem Erkennen eines Fehlers und einem return Code hinzugefügt werden muss, kann es lästig sein, einen try -Ausdruck in eine if -Anweisung umzuschreiben.

5) Benannte Rückgabewerte: Das ausführliche Dokument diskutiert dies ausführlich. Wenn dies das Hauptanliegen dieses Vorschlags ist, dann sind wir, denke ich, an einem guten Ort.

6) Optionales Handler-Argument für try : Das ausführliche Dokument behandelt dies ebenfalls. Siehe den Abschnitt über Entwurfsiterationen.

7) Die Verwendung gofmt zum Formatieren try -Ausdrücken, sodass sie besonders sichtbar sind, wäre sicherlich eine Option. Aber es würde einige der Vorteile von try wegnehmen, wenn es in einem Ausdruck verwendet wird.

8) Wir haben in Betracht gezogen, das Problem aus der Sicht der Fehlerbehandlung ( handle ) und nicht aus der Sicht der Fehlerprüfung ( try ) zu betrachten. Insbesondere haben wir kurz darüber nachgedacht, nur den Begriff eines Fehlerbehandlers einzuführen (ähnlich dem ursprünglichen Designentwurf, der auf der letztjährigen Gophercon vorgestellt wurde). Der Gedanke war, dass, wenn (und nur wenn) ein Handler deklariert wird, in Zuweisungen mit mehreren Werten, bei denen der letzte Wert vom Typ error ist, dieser Wert einfach in einer Zuweisung weggelassen werden kann. Der Compiler würde implizit prüfen, ob es nicht null ist, und wenn ja, zum Handler verzweigen. Das würde die explizite Fehlerbehandlung vollständig verschwinden lassen und jeden ermutigen, stattdessen einen Handler zu schreiben. Dies schien ein extremer Ansatz zu sein, da es völlig implizit wäre – die Tatsache, dass eine Überprüfung stattfindet, wäre unsichtbar.

9) Darf ich vorschlagen, dass wir den Namen an dieser Stelle nicht radeln. Sobald alle anderen Bedenken geklärt sind, ist ein besserer Zeitpunkt, um den Namen zu verfeinern.

Das soll nicht heißen, dass die Bedenken unbegründet sind – die obigen Antworten geben lediglich unsere derzeitige Denkweise wieder. Für die Zukunft wäre es gut, neue Bedenken (oder neue Beweise zur Untermauerung dieser Bedenken) zu kommentieren – eine bloße Wiederholung dessen, was bereits gesagt wurde, liefert uns keine weiteren Informationen.

Und schließlich scheint es, dass nicht jeder, der sich zu diesem Thema äußert, das ausführliche Dokument gelesen hat. Bitte tun Sie dies, bevor Sie einen Kommentar abgeben, um eine Wiederholung des bereits Gesagten zu vermeiden. Danke.

Dies ist kein Kommentar zum Vorschlag, sondern ein Tippfehlerbericht. Es wurde nicht behoben, seit der vollständige Vorschlag veröffentlicht wurde, also dachte ich, ich erwähne es:

func try(t1 T1, t1 T2, … tn Tn, te error) (T1, T2, … Tn)

sollte sein:

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

Würde es sich lohnen, offen verfügbaren Go-Code für Anweisungen zur Fehlerprüfung zu analysieren, um herauszufinden, ob sich die meisten Fehlerprüfungen wirklich wiederholen oder ob in den meisten Fällen mehrere Prüfungen innerhalb derselben Funktion unterschiedliche Kontextinformationen hinzufügen? Der Vorschlag wäre für den ersten Fall sehr sinnvoll, würde aber für den zweiten nicht helfen. Im letzteren Fall verwenden die Leute entweder weiterhin if err != nil oder geben das Hinzufügen von zusätzlichem Kontext auf, verwenden try() und greifen auf das Hinzufügen eines allgemeinen Fehlerkontexts pro Funktion zurück, was meiner Meinung nach schädlich wäre. Mit den kommenden Fehlerwertfunktionen erwarten wir, dass Leute häufiger Fehler mit mehr Informationen umschließen. Wahrscheinlich habe ich den Vorschlag falsch verstanden, aber AFAIU, dies hilft nur dann, die Boilerplate zu reduzieren, wenn alle Fehler einer einzelnen Funktion auf genau eine Weise umschlossen werden müssen, und hilft nicht, wenn eine Funktion fünf Fehler behandelt, die möglicherweise unterschiedlich umschlossen werden müssen. Ich bin mir nicht sicher, wie häufig solche Fälle in freier Wildbahn sind (ziemlich häufig in den meisten meiner Projekte), aber ich mache mir Sorgen, dass try() die Leute dazu ermutigen könnte, gemeinsame Wrapper pro Funktion zu verwenden, selbst wenn es sinnvoll wäre, verschiedene Fehler zu umschließen anders.

Nur ein kurzer Kommentar, der mit Daten eines kleinen Beispielsatzes unterlegt ist:

Wir schlagen eine neue integrierte Funktion namens try vor, die speziell dafür entwickelt wurde, die Boilerplate-if-Anweisungen zu eliminieren, die normalerweise mit der Fehlerbehandlung in Go verbunden sind

Wenn dies das Kernproblem ist, das durch diesen Vorschlag gelöst wird, finde ich, dass dieser „Boilerplate“ nur ~ 1,4 % meines Codes in Dutzenden von öffentlich verfügbaren Open-Source-Projekten mit insgesamt ~ 60.000 SLOC ausmacht.

Neugierig, ob jemand ähnliche Statistiken hat?

Bei einer viel größeren Codebasis wie Go selbst mit einem Gesamtvolumen von etwa ~1,6 Mio. SLOC entspricht dies etwa ~0,5 % der Codebasis mit Zeilen wie if err != nil .

Ist dies wirklich das wirkungsvollste Problem, das mit Go 2 gelöst werden kann?

Vielen Dank @griesemer , dass du dir die Zeit genommen hast, alle Ideen durchzugehen und explizit Gedanken zu liefern. Ich denke, dass es wirklich dazu beiträgt, dass die Gemeinschaft in diesem Prozess gehört wird.

1. @pierrec schlug vor, dass gofmt try-Ausdrücke geeignet formatieren könnte, um sie besser sichtbar zu machen.
   Alternativ könnte man vorhandenen Code kompakter machen, indem man gofmt erlaubt, if-Anweisungen zu formatieren, die auf Fehler in einer Zeile prüfen (@zeebo).

1. Die Verwendung gofmt zum Formatieren try -Ausdrücken, sodass sie besonders sichtbar sind, wäre sicherlich eine Option. Aber es würde einige der Vorteile von try wegnehmen, wenn es in einem Ausdruck verwendet wird.

Dies sind wertvolle Gedanken darüber, dass gofmt try formatieren muss, aber ich bin daran interessiert, ob es irgendwelche Gedanken gibt, insbesondere zu gofmt , die die Überprüfung der if -Anweisung zulassen der Fehler ist eine Zeile. Der Vorschlag wurde mit der Formatierung try in einen Topf geworfen, aber ich denke, es ist eine völlig orthogonale Sache. Danke.

@griesemer vielen Dank für die unglaubliche Arbeit, all die Kommentare durchzugehen und die meisten, wenn nicht alle Rückmeldungen zu beantworten 🎉

Eine Sache, die in Ihrem Feedback nicht angesprochen wurde, war die Idee, den Werkzeug-/Überprüfungsteil der Go-Sprache zu verwenden, um die Fehlerbehandlung zu verbessern, anstatt die Go-Syntax zu aktualisieren.

Mit der Landung des neuen LSP ( gopls ) scheint es beispielsweise ein perfekter Ort zu sein, um die Signatur einer Funktion zu analysieren und sich um die Fehlerbehandlungs-Boilerplate für den Entwickler zu kümmern, auch mit ordnungsgemäßer Umhüllung und Überprüfung.

@griesemer Ich bin mir sicher, dass dies nicht gut durchdacht ist, aber ich habe versucht, Ihren Vorschlag näher an etwas zu modifizieren, mit dem ich mich hier wohlfühlen würde: https://www.reddit.com/r/golang/comments/bwvyhe /proposal_a_builtin_go_error_check_function_try/eq22bqa?utm_source=share&utm_medium=web2x

@zeebo Es wäre einfach, gofmt if err != nil { return ...., err } in einer einzigen Zeile zu formatieren. Vermutlich wäre es nur für diese spezielle Art von if -Mustern, nicht für alle "kurzen" if -Anweisungen?

In ähnlicher Weise gab es Bedenken, dass try unsichtbar sein könnte, weil es auf derselben Linie wie die Geschäftslogik steht. Wir haben all diese Möglichkeiten:

Aktueller Stil:

a, b, c, ... err := BusinessLogic(...)
if err != nil {
   return ..., err
}

Einzeilig if :

a, b, c, ... err := BusinessLogic(...)
if err != nil { return ..., err }

try in einer separaten Zeile (!):

a, b, c, ... err := BusinessLogic(...)
try(err)

try wie vorgeschlagen:

a, b, c := try(BusinessLogic(...))

Die erste und die letzte Zeile scheinen (für mich) am klarsten zu sein, besonders wenn man sich daran gewöhnt hat, try als das zu erkennen, was es ist. Mit der letzten Zeile wird zwar explizit auf einen Fehler geprüft, aber da es (normalerweise) nicht die Hauptaktion ist, tritt es etwas mehr in den Hintergrund.

@marwan-at-work Ich bin mir nicht sicher, was Sie vorschlagen, dass die Tools für Sie tun. Schlagen Sie vor, dass sie die Fehlerbehandlung irgendwie verstecken?

@Dpinela

@guybrand Das scheint ein ganz anderer Vorschlag zu sein; Ich denke, Sie sollten es als eigene Ausgabe einreichen, damit sich diese auf die Diskussion des Vorschlags von @griesemer konzentrieren kann.

IMO unterscheidet sich mein Vorschlag nur in der Syntax, was bedeutet:

• Ziele sind in Inhalt und Priorität ähnlich.
• Die Idee, jeden Fehler in einer eigenen Zeile zu erfassen und dementsprechend (wenn nicht null) die Funktion zu verlassen, während eine Handler-Funktion durchlaufen wird, ist ähnlich (Pseudo-Asm - es ist ein "jnz" und "Call").
• Dies bedeutet sogar, dass die Anzahl der Zeilen in einem Funktionskörper (ohne die Verzögerung) und ein Fluss genau gleich aussehen würden (und dementsprechend würde AST wahrscheinlich auch gleich ausfallen).

Der Hauptunterschied besteht also darin, ob wir den ursprünglichen Funktionsaufruf mit try(func()) umschließen, das immer die letzte Variable analysiert, um den Aufruf zu jnz, oder ob wir dafür den tatsächlichen Rückgabewert verwenden.

Ich weiß, es sieht anders aus, aber eigentlich sehr ähnlich im Konzept.
Auf der anderen Seite - wenn Sie den üblichen Versuch unternehmen .... in vielen C-ähnlichen Sprachen zu fangen - wäre das eine ganz andere Implementierung, andere Lesbarkeit usw.

Ich denke jedoch ernsthaft darüber nach, einen Vorschlag zu schreiben, danke für die Idee.

@griesemer

Ich bin mir nicht sicher, was Sie vorschlagen, dass die Tools für Sie tun. Schlagen Sie vor, dass sie die Fehlerbehandlung irgendwie verstecken?

Ganz im Gegenteil: Ich schlage vor, dass gopls optional die Boilerplate für die Fehlerbehandlung für Sie schreiben kann.

Wie Sie in Ihrem letzten Kommentar erwähnt haben:

Der Grund für diesen Vorschlag ist, dass die Fehlerbehandlung (insbesondere der zugehörige Boilerplate-Code) von der Go-Community als ein bedeutendes Problem in Go (neben dem Fehlen von Generika) erwähnt wurde

Der Kern des Problems besteht also darin, dass der Programmierer am Ende eine Menge Boilerplate-Code schreibt. Es geht also ums Schreiben, nicht ums Lesen. Daher mein Vorschlag: Lassen Sie den Computer (tooling/gopls) das Schreiben für den Programmierer erledigen, indem Sie die Funktionssignatur analysieren und geeignete Fehlerbehandlungsklauseln platzieren.

Zum Beispiel:

// user begins to write this function: 
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  return bts, nil
}

Dann löst der Benutzer das Tool aus, vielleicht indem er einfach die Datei speichert (ähnlich wie gofmt/goimports normalerweise funktionieren) und gopls würde sich diese Funktion ansehen, ihre Rückgabesignatur analysieren und den Code so erweitern:

// user has triggered the tool (by saving the file, or code action)
func openFile(path string) ([]byte, error) {
  file, err := os.Open(path)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  defer file.Close()
  bts, err := ioutil.ReadAll(file)
  if err != nil {
    return nil, fmt.Errorf("openFile: %w", err)
  }
  return bts, nil
}

Auf diese Weise erhalten wir das Beste aus beiden Welten: Wir erhalten die Lesbarkeit/Eindeutigkeit des aktuellen Fehlerbehandlungssystems, und der Programmierer hat keine Fehlerbehandlungsbausteine ​​geschrieben. Noch besser, der Benutzer kann später die Fehlerbehandlungsblöcke ändern, um ein anderes Verhalten zu erzielen: gopls kann verstehen, dass der Block existiert, und es würde ihn nicht ändern.

Wie würde das Tool wissen, dass ich beabsichtigte, err später in der Funktion zu verarbeiten, anstatt vorzeitig zurückzukehren? Obwohl selten, aber Code habe ich trotzdem geschrieben.

Ich entschuldige mich, falls dies schon einmal erwähnt wurde, aber ich konnte keinen Hinweis darauf finden.

try(DoSomething()) liest sich gut für mich und macht Sinn: Der Code versucht, etwas zu tun. try(err) , OTOH, fühlt sich semantisch etwas daneben: Wie versucht man einen Fehler? Meiner Meinung nach könnte man einen Fehler _testen_ oder _überprüfen_, aber einen _versuchen_ scheint nicht richtig zu sein.

Mir ist klar, dass das Zulassen try(err) aus Konsistenzgründen wichtig ist: Ich nehme an, es wäre seltsam, wenn try(DoSomething()) funktionieren würde, aber err := DoSomething(); try(err) nicht. Trotzdem fühlt es sich so an, als würde try(err) auf der Seite etwas seltsam aussehen. Mir fallen keine anderen integrierten Funktionen ein, die so einfach so seltsam aussehen können.

Ich habe dazu keine konkreten Vorschläge, wollte aber dennoch diese Bemerkung machen.

@Griesemer Danke. Tatsächlich sollte der Vorschlag nur für return sein, aber ich vermute, dass es gut wäre, wenn jede einzelne Aussage eine einzelne Zeile sein könnte. Zum Beispiel in einem Test, den man ohne Änderungen an der Testbibliothek haben könnte

if err != nil { t.Fatal(err) }

Die erste und die letzte Zeile scheinen (für mich) am klarsten zu sein, besonders wenn man sich daran gewöhnt hat, try als das zu erkennen, was es ist. Mit der letzten Zeile wird zwar explizit auf einen Fehler geprüft, aber da es (normalerweise) nicht die Hauptaktion ist, tritt es etwas mehr in den Hintergrund.

Mit der letzten Zeile wird ein Teil der Kosten ausgeblendet. Wenn Sie den Fehler kommentieren möchten, von dem ich glaube, dass die Community lautstark gesagt hat, dass es sich um eine bewährte Vorgehensweise handelt und ermutigt werden sollte, müssten Sie die Funktionssignatur ändern, um die Argumente zu benennen, und hoffen, dass ein einzelnes defer angewendet wird jeder Ausgang im Funktionsrumpf, sonst hat try keinen Wert; vielleicht sogar negativ aufgrund seiner Leichtigkeit.

Ich habe nichts mehr hinzuzufügen, was meines Erachtens nicht schon gesagt wurde.

Ich habe nicht gesehen, wie ich diese Frage aus dem Designdokument beantworten soll. Was macht dieser Code:

func foo() (err error) {
    src := try(getReader())
    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }
        try(err)
        println(n)
    }
    return nil
}

Mein Verständnis ist, dass es entzuckern würde

func foo() (err error) {
    tsrc, te := getReader()
    if err != nil {
        err = te
        return
    }
    src := tsrc

    if src != nil {
        n, err := src.Read(nil)
        if err == io.EOF {
            return nil
        }

        terr := err
        if terr != nil {
            err = terr
            return
        }

        println(n)
    }
    return nil
}

die nicht kompiliert werden kann, weil err während einer nackten Rückkehr beschattet wird. Würde das nicht kompilieren? Wenn ja, ist das ein sehr subtiler Fehler und scheint nicht allzu unwahrscheinlich zu sein. Wenn nicht, dann ist mehr los als etwas Zucker.

@marwan-at-work

Wie Sie in Ihrem letzten Kommentar erwähnt haben:

Der Grund für diesen Vorschlag ist, dass die Fehlerbehandlung (insbesondere der zugehörige Boilerplate-Code) von der Go-Community als ein bedeutendes Problem in Go (neben dem Fehlen von Generika) erwähnt wurde

Der Kern des Problems besteht also darin, dass der Programmierer am Ende eine Menge Boilerplate-Code schreibt. Es geht also ums Schreiben, nicht ums Lesen.

Ich denke, es ist eigentlich umgekehrt - für mich ist das größte Ärgernis mit der aktuellen Fehlerbehandlungs-Boilerplate nicht so sehr, dass ich sie tippen muss, sondern wie sie den glücklichen Pfad der Funktion vertikal über den Bildschirm streut, was es schwieriger macht, sie zu verstehen ein Blick. Der Effekt ist besonders ausgeprägt in E/A-lastigem Code, wo normalerweise zwischen zwei Operationen ein Block mit Boilerplates steht. Selbst eine vereinfachte Version von CopyFile benötigt ~20 Zeilen, obwohl sie eigentlich nur fünf Schritte ausführt: Quelle öffnen, Quelle schließen verschieben, Ziel öffnen, Quelle kopieren -> Ziel, Ziel schließen.

Ein weiteres Problem mit der aktuellen Syntax besteht darin, dass Sie, wie ich bereits erwähnt habe, wenn Sie eine Kette von Operationen haben, von denen jede einen Fehler zurückgeben kann, die aktuelle Syntax Sie dazu zwingt, allen Zwischenergebnissen Namen zu geben, selbst wenn Sie dies vorziehen würden etwas anonym lassen. Wenn dies passiert, schadet es auch der Lesbarkeit, weil Sie Gehirnzyklen damit verbringen müssen, diese Namen zu analysieren, obwohl sie nicht sehr informativ sind.

Ich mag try in einer separaten Zeile.
Und ich hoffe, dass es handler func unabhängig spezifizieren kann.

func try(error, optional func(error)error)

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    try(err)

    handle := func(err error) error {
        tx.Rollback()
        return err
    }

    var res int64
    _, err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    try(err, handle)

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    try(err, handle)

    return tx.Commit()
}

@zeebo : Die Beispiele , die ich gegeben habe, sind 1: 1-Übersetzungen. Der erste (traditionelle if ) hat den Fehler nicht behandelt, und die anderen auch nicht. Wenn das erste den Fehler behandelt hat und dies die einzige Stelle wäre, an der ein Fehler in einer Funktion überprüft wird, könnte das erste Beispiel (mit einem if ) die geeignete Wahl zum Schreiben des Codes sein. Wenn es mehrere Fehlerprüfungen gibt, die alle dieselbe Fehlerbehandlung (Wrapping) verwenden, sagen wir, weil sie alle Informationen über die aktuelle Funktion hinzufügen, könnte man eine defer -Anweisung verwenden, um die Fehler alle an einem Ort zu behandeln. Optional könnte man die if 's in try 's umschreiben (oder sie in Ruhe lassen). Wenn mehrere Fehler zu überprüfen sind und sie alle unterschiedlich mit den Fehlern umgehen (was ein Zeichen dafür sein könnte, dass das Anliegen der Funktion zu weit gefasst ist und möglicherweise aufgeteilt werden muss), ist die Verwendung if Weg zu gehen. Ja, es gibt mehrere Möglichkeiten, dasselbe zu tun, und die richtige Wahl hängt sowohl vom Code als auch vom persönlichen Geschmack ab. Während wir in Go nach „one way to do one thing“ streben, ist dies natürlich bereits nicht der Fall, insbesondere für gängige Konstrukte. Wenn zum Beispiel eine if - else - if Sequenz zu lang wird, könnte manchmal eine switch angemessener sein. Manchmal drückt eine Variablendeklaration var x int die Absicht besser aus als x := 0 und so weiter (obwohl nicht jeder darüber glücklich ist).

Zu deiner Frage zum "rewrite": Nein, es gäbe keinen Kompilierungsfehler. Beachten Sie, dass das Umschreiben intern erfolgt (und möglicherweise effizienter ist, als das Codemuster vermuten lässt), und der Compiler sich nicht über eine verdeckte Rückgabe beschweren muss. In Ihrem Beispiel haben Sie eine lokale err -Variable in einem verschachtelten Bereich deklariert. try hätte natürlich immer noch direkten Zugriff auf die Ergebnisvariable err . Die Umschreibung könnte unter der Decke eher so aussehen .

[bearbeitet] PS: Eine bessere Antwort wäre: try ist keine nackte Rückkehr (auch wenn die Umschreibung so aussieht). Schließlich gibt man try explizit ein Argument, das den Fehler enthält (oder ist), der zurückgegeben wird, wenn nicht nil . Der Schattenfehler für nackte Rückgaben ist ein Fehler in der Quelle (nicht in der zugrunde liegenden Übersetzung der Quelle. Der Compiler benötigt den Fehler nicht.

Wenn der endgültige Rückgabetyp der übergeordneten Funktion nicht vom Typ error ist, können wir dann in Panik geraten?

Es wird das Builtin vielseitiger machen (wie z. B. mein Anliegen in #32219 befriedigen)

@pjebs Dies wurde in Betracht gezogen und dagegen entschieden. Bitte lesen Sie das ausführliche Designdokument (das sich ausdrücklich auf Ihr Problem zu diesem Thema bezieht).

Ich möchte auch darauf hinweisen, dass try() als Ausdruck behandelt wird, obwohl es als return-Anweisung funktioniert. Ja, ich weiß, dass try ein eingebautes Makro ist, aber die meisten Benutzer werden dies wie funktionale Programmierung verwenden, denke ich.

func doSomething() (error, error, error, error, error) {
   ...
}

try(try(try(try(try(doSomething)))))

Das Design besagt, dass Sie mit panic untersucht haben, anstatt mit dem Fehler zurückzukehren.

Ich betone einen feinen Unterschied:

Machen Sie genau das, was Ihr aktueller Vorschlag besagt, außer dass Sie die Einschränkung entfernen, dass die übergreifende Funktion einen endgültigen Rückgabetyp vom Typ error haben muss.

Wenn es keinen abschließenden Rückgabewert von error hat => Panik
Bei Verwendung von try für Variablendeklarationen auf Paketebene => Panik (entfernt die Notwendigkeit der MustXXX( ) -Konvention)

Für Einheitentests eine bescheidene Sprachänderung.

@mattn , ich bezweifle sehr, dass eine nennenswerte Anzahl von Leuten solchen Code schreiben wird.

@pjebs , diese Semantik - Panik, wenn in der aktuellen Funktion kein Fehlerergebnis auftritt - ist genau das, was das Designdokument in https://github.com/golang/proposal/blob/master/design/32437-try-builtin bespricht. md#Diskussion.

Bei dem Versuch, try nicht nur innerhalb von Funktionen mit einem Fehlerergebnis nützlich zu machen, hing die Semantik von try außerdem vom Kontext ab: Wenn try auf Paketebene verwendet oder innerhalb einer Funktion ohne ein Fehlerergebnis aufgerufen wurde, try würde in Panik geraten, wenn ein Fehler auftritt. (Nebenbei gesagt, wegen dieser Eigenschaft hieß das eingebaute in diesem Vorschlag eher must als try.) Sich try (oder must) auf diese kontextsensitive Weise zu verhalten, schien natürlich und auch ziemlich nützlich: Es würde die Eliminierung von ermöglichen viele benutzerdefinierte Must-Hilfsfunktionen, die derzeit in Initialisierungsausdrücken für Variablen auf Paketebene verwendet werden. Es würde auch die Möglichkeit eröffnen, try in Unit-Tests über das Testing-Paket zu verwenden.

Die Kontextsensitivität von try wurde jedoch als angespannt angesehen: Beispielsweise könnte sich das Verhalten einer Funktion, die try-Aufrufe enthält, stillschweigend ändern (von möglicherweise panisch zu nicht panisch und umgekehrt), wenn ein Fehlerergebnis zur Signatur hinzugefügt oder daraus entfernt wurde. Dies schien eine zu gefährliche Eigenschaft zu sein. Die offensichtliche Lösung wäre gewesen, die Funktionalität von try in zwei getrennte Funktionen aufzuteilen, must und try (sehr ähnlich zu dem, was in Issue #31442 vorgeschlagen wird). Aber das hätte zwei neue eingebaute Funktionen erfordert, wobei nur try direkt mit dem unmittelbaren Bedarf an besserer Unterstützung bei der Fehlerbehandlung verbunden wäre.

@pjebs Das ist _genau_ das, was wir in einem früheren Vorschlag berücksichtigt haben (siehe detailliertes Dokument, Abschnitt über Design-Iterationen, 4. Absatz):

Bei dem Versuch, try nicht nur innerhalb von Funktionen mit einem Fehlerergebnis nützlich zu machen, hing die Semantik von try außerdem vom Kontext ab: Wenn try auf Paketebene verwendet oder innerhalb einer Funktion ohne ein Fehlerergebnis aufgerufen wurde, try würde in Panik geraten, wenn ein Fehler auftritt. (Nebenbei gesagt, wegen dieser Eigenschaft hieß das eingebaute in diesem Vorschlag eher Muss als Versuch.)

Der (interne) Konsens des Go-Teams war, dass es für try verwirrend wäre, vom Kontext abhängig zu sein und sich so unterschiedlich zu verhalten. Beispielsweise könnte das Hinzufügen eines Fehlerergebnisses zu einer Funktion (oder das Entfernen) das Verhalten der Funktion stillschweigend von Panik zu Nicht-Panik (oder umgekehrt) ändern.

@griesemer Danke für die Klarstellung zum Umschreiben. Ich bin froh, dass es kompiliert wird.

Ich verstehe, dass die Beispiele Übersetzungen waren, die die Fehler nicht kommentierten. Ich habe versucht zu argumentieren, dass try es schwieriger macht, Fehler in gewöhnlichen Situationen gut zu kommentieren, und dass Fehlerkommentare für die Community sehr wichtig sind. Ein großer Teil der bisherigen Kommentare hat Möglichkeiten untersucht, try eine bessere Unterstützung für Anmerkungen hinzuzufügen.

Ich bin nicht der Meinung, dass die Fehler anders behandelt werden müssen, da dies ein Zeichen dafür ist, dass das Anliegen der Funktion zu weit gefasst ist. Ich habe einige Beispiele für behaupteten echten Code aus den Kommentaren übersetzt und sie in einem Dropdown-Menü am Ende meines ursprünglichen Kommentars platziert, und das Beispiel in https://github.com/golang/go/issues/32437#issuecomment - 499007288 Ich denke, demonstriert einen gemeinsamen Fall gut:

func (c *Config) Build() error {
    pkgPath, err := c.load()
    if err != nil { return nil, errors.WithMessage(err, "load config dir") }

    b := bytes.NewBuffer(nil)
    err = templates.ExecuteTemplate(b, "main", c)
    if err != nil { return nil, errors.WithMessage(err, "execute main template") }

    buf, err := format.Source(b.Bytes())
    if err != nil { return nil, errors.WithMessage(err, "format main template") }

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    err = ioutil.WriteFile(target, buf, 0644)
    if err != nil { return nil, errors.WithMessagef(err, "write file %s", target) }
    // ...
}

Der Zweck dieser Funktion besteht darin, eine Vorlage für einige Daten in einer Datei auszuführen. Ich glaube nicht, dass es aufgeteilt werden muss, und es wäre bedauerlich, wenn all diese Fehler nur die Linie erhalten würden, auf der sie durch eine Verzögerung erstellt wurden. Das mag für Entwickler in Ordnung sein, aber es ist viel weniger nützlich für Benutzer.

Ich denke, es ist auch ein kleines Signal dafür, wie subtil die defer wrap(&err, "message: %v", err) Bugs waren und wie sie sogar erfahrenen Go-Programmierern ein Bein stellten.

Um mein Argument zusammenzufassen : Ich denke, dass die Fehleranmerkung wichtiger ist als die ausdrucksbasierte Fehlerprüfung, und wir können einiges an Rauschunterdrückung erreichen, indem wir die Anweisungsbasierte Fehlerprüfung auf eine Zeile statt auf drei beschränken. Danke.

@griesemer Entschuldigung, ich habe einen anderen Abschnitt gelesen, in dem es um Panik ging, und die Diskussion über die Gefahren nicht gesehen.

@zeebo Danke für dieses Beispiel. Es sieht so aus, als wäre die Verwendung einer if -Anweisung in diesem Fall genau die richtige Wahl. Aber auf den Punkt gebracht, kann die Formatierung der ifs in Einzeiler dies ein wenig rationalisieren.

Ich möchte noch einmal die Idee eines Handlers als zweites Argument für try aufbringen, aber mit dem Zusatz, dass das Handler-Argument _erforderlich_, aber nil-fähig ist. Dadurch wird die Behandlung des Fehlers zur Standardeinstellung und nicht zur Ausnahme. In Fällen, in denen Sie den Fehler wirklich unverändert weitergeben möchten, geben Sie dem Handler einfach einen Nullwert an, und try verhält sich genauso wie im ursprünglichen Vorschlag, aber das Argument Null fungiert als visueller Hinweis darauf, dass die Fehler wird nicht behandelt. Es wird während der Codeüberprüfung einfacher zu erkennen sein.

file := try(os.Open("my_file.txt"), nil)

Was soll passieren, wenn der Handler bereitgestellt wird, aber null ist? Sollte es Panik versuchen oder als abwesender Fehlerbehandler behandelt werden?

Wie oben erwähnt, wird sich try gemäß dem ursprünglichen Vorschlag verhalten. Es gäbe keinen abwesenden Fehlerbehandler, nur einen Null-Fehlerbehandler.

Was ist, wenn der Handler mit einem Nicht-Null-Fehler aufgerufen wird und dann ein Null-Ergebnis zurückgibt? Bedeutet dies, dass der Fehler „storniert“ ist? Oder sollte die einschließende Funktion mit einem Nullfehler zurückkehren?

Ich glaube, dass die einschließende Funktion mit einem Nullfehler zurückkehren würde. Es wäre möglicherweise sehr verwirrend, wenn try die Ausführung manchmal fortsetzen könnte, selbst nachdem es einen Nicht-Null-Fehlerwert erhalten hat. Dies würde Handlern ermöglichen, sich unter bestimmten Umständen um den Fehler zu kümmern. Dieses Verhalten könnte beispielsweise in einer Funktion im Stil "Get or Create" nützlich sein.

func getOrCreateObject(obj *object) error {
    defaultObjectHandler := func(err error) error {
        if err == ObjectDoesNotExistErr {
            *obj = object{}
            return nil
        }
        return fmt.Errorf("getting or creating object: %v", err)
    }

    *obj = try(db.getObject(), defaultObjectHandler)
}

Es war auch nicht klar, ob das Zulassen einer optionalen Fehlerbehandlung dazu führen würde, dass Programmierer die ordnungsgemäße Fehlerbehandlung insgesamt ignorieren würden. Es wäre auch einfach, überall eine ordnungsgemäße Fehlerbehandlung durchzuführen, aber ein einziges Auftreten eines Versuchs zu verpassen. Und so weiter.

Ich glaube, dass diese beiden Bedenken gemildert werden, indem der Handler zu einem erforderlichen, nicht brauchbaren Argument gemacht wird. Es erfordert, dass Programmierer eine bewusste, explizite Entscheidung treffen, dass sie ihren Fehler nicht behandeln.

Als Bonus denke ich, dass das Erfordernis des Fehlerbehandlers auch tief verschachtelte try s entmutigt, weil sie weniger kurz sind. Einige mögen dies als Nachteil sehen, aber ich denke, es ist ein Vorteil.

@velovix Ich liebe die Idee, aber warum muss ein Fehlerbehandler erforderlich sein? Kann es nicht standardmäßig nil sein? Warum brauchen wir einen „visuellen Hinweis“?

@griesemer Was wäre, wenn die Idee von @velovix übernommen würde, aber mit builtin , das eine vordefinierte Funktion enthält, die Fehler in Panik umwandelt UND wir die Anforderung entfernen, dass die übergreifende Funktion einen Fehlerrückgabewert hat?

Die Idee ist, wenn die übergreifende Funktion keinen Fehler zurückgibt, ist die Verwendung try ohne Error-Handler ein Kompilierzeitfehler.

Der Fehlerhandler kann auch verwendet werden, um den bald zurückgegebenen Fehler mithilfe verschiedener Bibliotheken usw. an der Fehlerstelle einzuschließen, anstatt ein defer oben, das einen benannten zurückgegebenen Fehler modifiziert.

@pjebs

Warum muss ein Error-Handler benötigt werden? Kann es nicht standardmäßig null sein? Warum brauchen wir einen „visuellen Hinweis“?

Damit soll auf die Bedenken eingegangen werden

1. Der try -Vorschlag, wie er jetzt vorliegt, könnte Leute davon abhalten, Kontext zu ihren Fehlern zu liefern, weil dies nicht ganz so einfach ist.

Einen Handler an erster Stelle zu haben, erleichtert das Bereitstellen von Kontext, und wenn der Handler ein erforderliches Argument ist, wird eine Nachricht gesendet: Der übliche, empfohlene Fall besteht darin, den Fehler auf irgendeine Weise zu behandeln oder zu kontextualisieren, und nicht einfach den Stapel hochzureichen. Es entspricht der allgemeinen Empfehlung der Go-Community.

1. Ein Anliegen aus dem ursprünglichen Vorschlagsdokument. Ich habe es in meinem ersten Kommentar zitiert:

Es war auch nicht klar, ob das Zulassen einer optionalen Fehlerbehandlung dazu führen würde, dass Programmierer die ordnungsgemäße Fehlerbehandlung insgesamt ignorieren würden. Es wäre auch einfach, überall eine ordnungsgemäße Fehlerbehandlung durchzuführen, aber ein einziges Auftreten eines Versuchs zu verpassen. Und so weiter.

Ein explizites nil übergeben zu müssen, macht es schwieriger zu vergessen, einen Fehler richtig zu behandeln. Sie müssen sich explizit dafür entscheiden, den Fehler nicht zu behandeln, anstatt dies implizit durch Weglassen eines Arguments zu tun.

Denken Sie weiter über die unter https://github.com/golang/go/issues/32437#issuecomment -498947603 kurz erwähnte bedingte Rückgabe nach.
Es scheint
return if f, err := os.Open("/my/file/path"); err != nil
würde besser mit dem Aussehen von Gos existierendem if konform gehen.

Wenn wir eine Regel für die return if Anweisung hinzufügen, dass
wenn der letzte Bedingungsausdruck (wie err != nil ) nicht vorhanden ist,und die letzte Variable der Deklaration in der Anweisung return if ist vom Typ error ,dann wird der Wert der letzten Variablen automatisch mit nil als implizite Bedingung verglichen.

Dann kann die return if -Anweisung abgekürzt werden zu:
return if f, err := os.Open("my/file/path")

Das kommt dem Signal-Rausch-Verhältnis sehr nahe, das der try bietet.
Wenn wir return if in try ändern, wird es
try f, err := os.Open("my/file/path")
Es ähnelt wieder anderen vorgeschlagenen Variationen des try in diesem Thread, zumindest syntaktisch.
Ich persönlich bevorzuge in diesem Fall immer noch return if gegenüber try , weil es die Austrittspunkte einer Funktion sehr deutlich macht. Zum Beispiel hebe ich beim Debuggen oft das Schlüsselwort return im Editor hervor, um alle Austrittspunkte einer großen Funktion zu identifizieren.

Leider scheint es auch bei der Unannehmlichkeit des Einfügens von Debug-Protokollen nicht genug zu helfen.
Es sei denn, wir erlauben auch einen body Block für return if , wie
Original:

        return if f, err := os.Open("my/path") 

Beim Debuggen:

-       return if f, err := os.Open("my/path") 
+       return if f, err := os.Open("my/path") {
+               fmt.Printf("DEBUG: os.Open: %s\n", err)
+       }

Die Bedeutung des Körperblocks von return if ist offensichtlich, nehme ich an. Es wird vor defer und zurück ausgeführt.

Allerdings habe ich keine Beschwerden über den bestehenden Fehlerbehandlungsansatz in Go.
Ich mache mir mehr Sorgen darüber, wie sich das Hinzufügen der neuen Fehlerbehandlung auf die derzeitige Güte von Go auswirken würde.

@velovix Uns gefiel die Idee eines try mit einer expliziten Handler-Funktion als 2. Argument sehr gut. Aber es gab zu viele Fragen, auf die es keine offensichtlichen Antworten gab, wie das Designdokument feststellt. Sie haben einige davon auf eine Weise beantwortet, die Ihnen vernünftig erscheint. Es ist sehr wahrscheinlich (und das war unsere Erfahrung innerhalb des Go-Teams), dass jemand anderes denkt, dass die richtige Antwort eine ganz andere ist. Zum Beispiel geben Sie an, dass das Handler-Argument immer angegeben werden sollte, aber dass es nil sein kann, um es deutlich zu machen, wir kümmern uns nicht um die Behandlung des Fehlers. Was passiert nun, wenn man einen Funktionswert (kein nil -Literal) bereitstellt und dieser Funktionswert (in einer Variablen gespeichert) zufällig null ist? Analog zum expliziten nil ist keine Handhabung erforderlich. Aber andere könnten argumentieren, dass dies ein Fehler im Code ist. Oder alternativ könnte man nullwertige Handler-Argumente zulassen, aber dann könnte eine Funktion in einigen Fällen Fehler inkonsistent behandeln und in anderen nicht, und es ist nicht unbedingt aus dem Code ersichtlich, was man tut, weil es so aussieht, als ob ein Handler immer vorhanden ist . Ein weiteres Argument war, dass es besser ist, eine Fehlerbehandlungsroutine auf oberster Ebene zu deklarieren, da dies sehr deutlich macht, dass die Funktion Fehler behandelt. Daher die defer . Wahrscheinlich gibt es noch mehr.

Es wäre gut, mehr über dieses Anliegen zu erfahren. Der aktuelle Codierungsstil, der if-Anweisungen zum Testen auf Fehler verwendet, ist so explizit wie möglich. Es ist sehr einfach, auf individueller Basis (für jedes if) zusätzliche Informationen zu einem Fehler hinzuzufügen. Oftmals ist es sinnvoll, alle in einer Funktion erkannten Fehler einheitlich zu behandeln, was mit einem defer geschehen kann – dies ist bereits heute möglich. Es ist die Tatsache, dass wir bereits alle Werkzeuge für eine gute Fehlerbehandlung in der Sprache haben, und das Problem, dass ein Handler-Konstrukt nicht orthogonal zum Zurückstellen ist, was uns dazu veranlasste, einen neuen Mechanismus allein zum Erweitern von Fehlern wegzulassen.

@griesemer - IIUC, Sie sagen, dass für callsite-abhängige Fehlerkontexte die aktuelle if-Anweisung in Ordnung ist. Dagegen ist diese neue try -Funktion für die Fälle nützlich, in denen die Behandlung mehrerer Fehler an einer einzigen Stelle sinnvoll ist.

Ich glaube, die Sorge war, dass, obwohl es in einigen Fällen in Ordnung sein kann, einfach ein if err != nil { return err} zu machen, es normalerweise empfohlen wird, den Fehler vor der Rückkehr zu dekorieren. Und dieser Vorschlag scheint sich mit dem vorherigen zu befassen und tut nicht viel für das letztere. Was im Wesentlichen bedeutet, dass die Leute ermutigt werden, ein Muster mit einfacher Rückgabe zu verwenden.

@agnivade Sie haben Recht, dieser Vorschlag hilft genau nicht bei der Fehlerdekoration (sondern um die Verwendung von defer zu empfehlen). Ein Grund dafür ist, dass es dafür bereits Sprachmechanismen gibt. Sobald eine Fehlerdekoration erforderlich ist, insbesondere auf Einzelfehlerbasis, macht die zusätzliche Menge an Quelltext für den Dekorationscode das if im Vergleich weniger belastend. In Fällen, in denen keine Dekoration erforderlich ist oder die Dekoration immer gleich ist, wird die Boilerplate zu einem sichtbaren Ärgernis und lenkt dann vom wichtigen Code ab.

Die Leute werden bereits ermutigt, ein Muster mit einfacher Rückkehr zu verwenden, try oder kein try , es gibt nur weniger zu schreiben. Wenn ich darüber nachdenke, _die einzige Möglichkeit, Fehlerdekoration zu fördern, besteht darin, sie obligatorisch zu machen_, denn egal, welche Sprachunterstützung verfügbar ist, die Dekoration von Fehlern erfordert mehr Arbeit.

Eine Möglichkeit, den Deal zu versüßen, wäre, so etwas wie try (oder eine analoge Abkürzungsnotation) nur zuzulassen, _wenn_ irgendwo ein expliziter (möglicherweise leerer) Handler bereitgestellt wird (beachten Sie, dass der ursprüngliche Entwurfsentwurf keinen solchen hatte Anforderung auch nicht).

Ich bin mir nicht sicher, ob wir so weit gehen wollen. Lassen Sie mich noch einmal sagen, dass eine Menge perfekter Code, sagen wir Interna einer Bibliothek, nicht überall Fehler schmücken muss. Es ist beispielsweise in Ordnung, Fehler einfach zu verbreiten und zu dekorieren, bevor sie die API-Einstiegspunkte verlassen. (Sie überall auszuschmücken führt tatsächlich nur zu übertriebenen Fehlern, die es schwieriger machen, die wichtigen Fehler zu lokalisieren, wenn die wirklichen Übeltäter verborgen sind; ähnlich wie eine übermäßig ausführliche Protokollierung es schwierig machen kann, zu erkennen, was wirklich vor sich geht).

Ich denke, wir können auch eine Fangfunktion hinzufügen, was ein nettes Paar wäre, also:

func a() int {
  x := randInt()
  // let's assume that this is what recruiters should "fix" for us
  // or this happens in 3rd-party package.
  if x % 1337 != 0 {
    panic("not l33t enough")
  }
  return x
}

func b() error {
  // if a() panics, then x = 0, err = error{"not l33t enough"}
  x, err := catch(a())
  if err != nil {
    return err
  }
  sendSomewhereElse(x)
  return nil
}

// which could be simplified even further

func c() error {
  x := try(catch(a()))
  sendSomewhereElse(x)
  return nil
}

In diesem Beispiel wäre catch() recover() eine Panik und return ..., panicValue .
Natürlich haben wir einen offensichtlichen Eckfall, in dem wir eine Funktion haben, die auch einen Fehler zurückgibt. In diesem Fall denke ich, dass es praktisch wäre, den Fehlerwert einfach weiterzugeben.

Im Grunde können Sie also catch() verwenden, um Panikattacken tatsächlich zu beheben und sie in Fehler umzuwandeln.
das sieht für mich ziemlich komisch aus, weil Go eigentlich keine Ausnahmen hat, aber in diesem Fall haben wir ein ziemlich nettes try()-catch()-Muster, das auch nicht Ihre gesamte Codebasis mit so etwas wie Java ( catch(Throwable) im Hauptmenü + throws LiterallyAnything ). Sie können die Panik von jemandem leicht verarbeiten, als wären es übliche Fehler. Ich habe derzeit etwa 6 Millionen LoC in Go in meinem aktuellen Projekt, und ich denke, dies würde die Dinge zumindest für mich vereinfachen.

@griesemer Danke für deine Zusammenfassung der Diskussion.

Mir fällt auf, dass ein Punkt darin fehlt: Einige Leute haben argumentiert, dass wir mit dieser Funktion warten sollten, bis wir Generika haben, die es uns hoffentlich ermöglichen, dieses Problem auf elegantere Weise zu lösen.

Darüber hinaus gefällt mir auch der Vorschlag von @velovix , und obwohl ich zu schätzen weiß, dass dies einige Fragen aufwirft, wie in der Spezifikation beschrieben, denke ich, dass diese leicht auf vernünftige Weise beantwortet werden können, wie es @velovix bereits getan hat.

Zum Beispiel:

• Was passiert, wenn man einen Funktionswert (kein Null-Literal) bereitstellt und dieser Funktionswert (in einer Variablen gespeichert) zufällig Null ist? => Behandeln Sie den Fehler nicht, Punkt. Dies ist nützlich, wenn die Fehlerbehandlung vom Kontext abhängt und die Handler-Variable abhängig davon gesetzt wird, ob eine Fehlerbehandlung erforderlich ist oder nicht. Das ist kein Bug, sondern ein Feature. :)

• Ein weiteres Argument war, dass es besser ist, eine Fehlerbehandlungsroutine auf oberster Ebene zu deklarieren, da dies sehr deutlich macht, dass die Funktion Fehler behandelt. => Definieren Sie also den Fehlerbehandler am Anfang der Funktion als benannte Abschlussfunktion und verwenden Sie diese, sodass auch klar ist, dass der Fehler behandelt werden sollte. Dies ist kein ernstes Problem, eher eine Stilanforderung.

Welche anderen Bedenken gab es? Ich bin mir ziemlich sicher, dass sie alle auf vernünftige Weise ähnlich beantwortet werden können.

Schließlich, wie Sie sagen, "eine Möglichkeit, den Deal zu versüßen, wäre, so etwas wie try (oder eine analoge Abkürzungsnotation) nur zuzulassen, wenn irgendwo ein expliziter (möglicherweise leerer) Handler bereitgestellt wird". Ich denke, wenn wir mit diesem Vorschlag fortfahren wollen, sollten wir es tatsächlich "bis hierher" bringen, um eine ordnungsgemäße "explizite ist besser als implizite" Fehlerbehandlung zu fördern.

@griesemer

Was passiert nun, wenn man einen Funktionswert (kein Null-Literal) bereitstellt und dieser Funktionswert (in einer Variablen gespeichert) zufällig Null ist? Analog zum expliziten Nullwert ist keine Behandlung erforderlich. Aber andere könnten argumentieren, dass dies ein Fehler im Code ist.

Theoretisch scheint dies ein potenzieller Fallstrick zu sein, obwohl es mir schwer fällt, mir eine vernünftige Situation vorzustellen, in der ein Handler versehentlich Null sein würde. Ich stelle mir vor, dass Handler am häufigsten entweder aus einer an anderer Stelle definierten Hilfsfunktion oder als in der Funktion selbst definierter Abschluss stammen. Beides wird wahrscheinlich nicht unerwartet null werden. Sie könnten theoretisch ein Szenario haben, in dem Handler-Funktionen als Argumente an andere Funktionen weitergegeben werden, aber in meinen Augen scheint es ziemlich weit hergeholt. Vielleicht gibt es so ein Muster, das ich nicht kenne.

Ein weiteres Argument war, dass es besser ist, eine Fehlerbehandlungsroutine auf oberster Ebene zu deklarieren, da dies sehr deutlich macht, dass die Funktion Fehler behandelt. Daher die defer .

Wie @beoran erwähnte, würde das Definieren des Handlers als Abschluss am oberen Rand der Funktion im Stil sehr ähnlich aussehen, und so gehe ich persönlich davon aus, dass die Leute Handler am häufigsten verwenden würden. Obwohl ich die Klarheit schätze, die durch die Tatsache gewonnen wird, dass alle Funktionen, die Fehler behandeln, defer verwenden, kann es weniger klar werden, wenn eine Funktion in ihrer Fehlerbehandlungsstrategie auf halbem Weg nach unten in der Funktion schwenken muss. Dann gibt es zwei defer zu sehen und der Leser muss darüber nachdenken, wie sie miteinander interagieren werden. Dies ist eine Situation, in der ich glaube, dass ein Handler-Argument sowohl klarer als auch ergonomischer wäre, und ich denke, dass dies ein _relativ_ häufiges Szenario sein wird.

Ist es möglich, dass es ohne Klammern funktioniert?

Dh sowas wie:
a := try func(some)

@Cyberax - Wie bereits oben erwähnt, ist es sehr wichtig, dass Sie das Designdokument sorgfältig lesen, bevor Sie es veröffentlichen. Da es sich um eine stark frequentierte Ausgabe handelt, haben viele Leute abonniert.

Das Dokument behandelt Operatoren vs. Funktionen im Detail.

Ich mag das viel mehr als ich die August-Version mochte.

Ich denke, dass ein Großteil des negativen Feedbacks, das Rücksendungen ohne das Schlüsselwort return nicht direkt widerspricht, in zwei Punkten zusammengefasst werden kann:

1. Menschen mögen keine benannten Ergebnisparameter, die in den meisten Fällen erforderlich wären
2. es rät davon ab, detaillierten Kontext zu Fehlern hinzuzufügen

Siehe zum Beispiel:

• https://github.com/golang/go/issues/32437#issuecomment -498937169
• https://github.com/golang/go/issues/32437#issuecomment -498967099
• https://github.com/golang/go/issues/32437#issuecomment -499194787
• https://github.com/golang/go/issues/32437#issuecomment -499309304

Die Widerlegung dieser beiden Einwände lautet jeweils:

1. "wir entschieden, dass [benannte Ergebnisparameter] in Ordnung waren"
2. "Niemand wird Sie dazu zwingen, try zu verwenden" / es wird nicht für 100 % der Fälle angemessen sein

Ich habe nicht wirklich etwas zu 1 zu sagen (ich fühle mich nicht stark danach). Aber zu 2 möchte ich anmerken, dass der August-Vorschlag dieses Problem nicht hatte, die meisten Gegenvorschläge haben dieses Problem auch nicht.

Insbesondere hatte weder der tryf -Gegenvorschlag (der zweimal unabhängig voneinander in diesem Thread gepostet wurde) noch der try(X, handlefn) -Gegenvorschlag (der Teil der Design-Iterationen war) dieses Problem.

Ich denke, es ist schwer zu argumentieren, dass try , so wie es ist, die Leute davon abhält, Fehler mit relevantem Kontext zu dekorieren, und zu einer einzigen generischen Fehlerdekoration pro Funktion führt.

Aus diesen Gründen denke ich, dass es sich lohnt, dieses Problem anzugehen, und ich möchte eine mögliche Lösung vorschlagen:

1. Derzeit kann der Parameter von defer nur ein Funktions- oder Methodenaufruf sein. Erlauben Sie defer auch einen Funktionsnamen oder ein Funktionsliteral zu haben, dh

defer func(...) {...}
defer packageName.functionName

1. Wenn Panic oder Deferreturn auf diese Art von Verzögerung stoßen, rufen sie die Funktion auf und übergeben den Nullwert für alle ihre Parameter

2. try darf mehr als einen Parameter haben

3. Wenn try auf den neuen Verzögerungstyp trifft, ruft es die Funktion auf und übergibt einen Zeiger auf den Fehlerwert als ersten Parameter, gefolgt von allen eigenen Parametern von try , außer dem ersten.

Zum Beispiel gegeben:

func errorfn() error {
    return errors.New("an error")
}


func f(fail bool) {
    defer func(err *error, a, b, c int) {
        fmt.Printf("a=%d b=%d c=%d\n", a, b, c)
    }
    if fail {
        try(errorfn, 1, 2, 3)
    }
}

Folgendes wird passieren:

f(false)        // prints "a=0 b=0 c=0"
f(true)         // prints "a=1 b=2 c=3"

Der Code in https://github.com/golang/go/issues/32437#issuecomment -499309304 von @zeebo könnte dann wie folgt umgeschrieben werden:

func (c *Config) Build() error {
    defer func(err *error, msg string, args ...interface{}) {
        if *err == nil || msg == "" {
            return
        }
        *err = errors.WithMessagef(err, msg, args...)
    }
    pkgPath := try(c.load(), "load config dir")

    b := bytes.NewBuffer(nil)
    try(templates.ExecuteTemplate(b, "main", c), "execute main template")

    buf := try(format.Source(b.Bytes()), "format main template")

    target := fmt.Sprintf("%s.go", filename(pkgPath))
    try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)
    // ...
}

Und Definieren von ErrorHandlef als:

func HandleErrorf(err *error, format string, args ...interface{}) {
        if *err != nil && format != "" {
                *err = fmt.Errorf(format + ": %v", append(args, *err)...)
        }
}

würde jedem das begehrte tryf kostenlos geben, ohne Formatzeichenfolgen im fmt -Stil in die Kernsprache zu ziehen.

Diese Funktion ist abwärtskompatibel, da defer keine Funktionsausdrücke als Argument zulässt. Es werden keine neuen Schlüsselwörter eingeführt.
Die Änderungen, die vorgenommen werden müssen, um es zu implementieren, sind zusätzlich zu den in https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md beschriebenen:

1. dem Parser die neue Art des Zurückstellens beibringen
2. Ändern Sie den Typprüfer, um zu überprüfen, ob innerhalb einer Funktion alle Verzögerungen, die eine Funktion als Parameter (anstelle eines Aufrufs) haben, auch dieselbe Signatur haben
3. Ändern Sie den Typprüfer, um zu überprüfen, ob die an try übergebenen Parameter mit der Signatur der an defer übergebenen Funktionen übereinstimmen
4. Ändern Sie das Backend (?), um den entsprechenden deferproc-Aufruf zu generieren
5. Ändern Sie die Implementierung von try , um seine Argumente in die Argumente des verzögerten Aufrufs zu kopieren, wenn es auf einen Anruf stößt, der durch die neue Art von Verzögerung verzögert wird.

Nach der Komplexität des check/handle -Entwurfs war ich angenehm überrascht, als ich sah, dass dieser viel einfachere und pragmatischere Vorschlag landete, obwohl ich enttäuscht bin, dass es so viel Widerstand dagegen gegeben hat.

Zugegebenermaßen kommt ein Großteil des Widerstands von Leuten, die mit der gegenwärtigen Ausführlichkeit (eine absolut vernünftige Position) recht zufrieden sind und die vermutlich keinen Vorschlag begrüßen würden, sie zu mildern. Für den Rest von uns denke ich, dass dieser Vorschlag den idealen Punkt trifft, einfach und Go-artig zu sein, nicht zu viel zu versuchen und gut mit den bestehenden Fehlerbehandlungstechniken zu harmonieren, auf die Sie immer zurückgreifen könnten, wenn try hat nicht genau das getan, was Sie wollten.

Zu einigen konkreten Punkten:

1. Das einzige, was ich an dem Vorschlag nicht mag, ist die Notwendigkeit, einen benannten Fehlerrückgabeparameter zu haben, wenn defer verwendet wird, aber ich kann mir keine andere Lösung vorstellen, die nicht im Widerspruch dazu stehen würde wie der Rest der Sprache funktioniert. Ich denke also, dass wir das einfach akzeptieren müssen, wenn der Vorschlag angenommen wird.

2. Schade, dass try nicht gut mit dem Testpaket für Funktionen zusammenspielt, die keinen Fehlerwert zurückgeben. Meine eigene bevorzugte Lösung dafür wäre eine zweite eingebaute Funktion (vielleicht ptry oder must ), die immer in Panik geriet, anstatt zurückzukehren, wenn sie auf einen Nicht-Null-Fehler stieß und dies daher sein könnte Wird mit den oben genannten Funktionen verwendet (einschließlich main ). Obwohl diese Idee in der vorliegenden Iteration des Vorschlags abgelehnt wurde, hatte ich den Eindruck, dass es sich um eine „knappe Entscheidung“ handelte und daher für eine erneute Prüfung in Betracht kommen könnte.

3. Ich denke, es wäre schwierig für die Leute, herauszufinden, was go try(f) oder defer try(f) getan haben, und dass es daher am besten ist, sie einfach ganz zu verbieten.

4. Ich stimme mit denen überein, die denken, dass die bestehenden Techniken zur Fehlerbehandlung weniger ausführlich aussehen würden, wenn go fmt keine einzeiligen if -Anweisungen neu schreiben würde. Persönlich würde ich eine einfache Regel vorziehen, dass dies für _jede_ einzelne Anweisung if erlaubt wäre, unabhängig davon, ob es um die Fehlerbehandlung geht oder nicht. Tatsächlich konnte ich nie verstehen, warum dies derzeit nicht zulässig ist, wenn einzeilige Funktionen geschrieben werden, bei denen der Körper in derselben Zeile platziert wird, in der die Deklaration zulässig ist.

Bei Dekorationsfehlern

func myfunc()( err error){
try(thing())
defer func(){
err = errors.Wrap(err,"more context")
}()
}

Dies fühlt sich wesentlich ausführlicher und schmerzhafter an als die bestehenden Paradigmen und nicht so prägnant wie check/handle. Die try()-Variante ohne Umbruch ist prägnanter, aber es fühlt sich an, als würden die Leute am Ende eine Mischung aus try und einfachen Fehlerrückgaben verwenden. Ich bin mir nicht sicher, ob mir die Idee gefällt, Try und einfache Fehlerrückgaben zu mischen, aber ich bin total begeistert davon, Fehler zu dekorieren (und freue mich auf Is/As). Lassen Sie mich denken, dass dies zwar syntaktisch ordentlich ist, aber ich bin mir nicht sicher, ob ich es tatsächlich verwenden möchte. check/handle fühlte etwas, das ich gründlicher umarmen würde.

Ich mag die Einfachheit und den „eine Sache gut machen“-Ansatz sehr. In meinem GoAWK- Interpreter wäre es sehr hilfreich – ich habe ungefähr 100 if err != nil { return nil } -Konstrukte, die es vereinfachen und aufräumen würde, und das in einer ziemlich kleinen Codebasis.

Ich habe die Begründung des Vorschlags gelesen, es zu einem eingebauten und nicht zu einem Schlüsselwort zu machen, und es läuft darauf hinaus, dass der Parser nicht angepasst werden muss. Aber ist das nicht eine relativ kleine Menge Schmerz für Compiler- und Tooling-Autoren, während die zusätzlichen Klammern und die Lesbarkeitsprobleme, die wie eine Funktion aussehen, aber nicht sind, etwas für alle Go-Codierer und Code- Leser müssen aushalten. Meiner Meinung nach ist das Argument (Entschuldigung? :-), dass "aber panic() den Fluss kontrolliert" nicht stichhaltig, da Panik und Erholung von Natur aus außergewöhnlich sind, während try() dies tun wird normale Fehlerbehandlung und Kontrollfluss sein.

Ich würde es auf jeden Fall begrüßen, auch wenn dies so geschehen würde, aber ich würde es stark bevorzugen, wenn der normale Kontrollfluss klar ist, dh über ein Schlüsselwort erfolgt.

Ich bin für diesen Vorschlag. Es vermeidet meinen größten Vorbehalt gegenüber dem vorherigen Vorschlag: die Nicht-Orthogonalität von handle in Bezug auf defer .

Ich möchte zwei Aspekte erwähnen, die meiner Meinung nach oben nicht hervorgehoben wurden.

Erstens, obwohl dieser Vorschlag es nicht einfach macht, kontextspezifischen Fehlertext zu einem Fehler hinzuzufügen, _macht_ er es einfach, Stack-Frame-Fehlerverfolgungsinformationen zu einem Fehler hinzuzufügen: https://play.golang.org/p /YL1MoqR08E6

Zweitens ist try wohl eine faire Lösung für die meisten Probleme, die https://github.com/golang/go/issues/19642 zugrunde liegen. Um ein Beispiel für dieses Problem zu nehmen, könnten Sie try verwenden, um zu vermeiden, dass jedes Mal alle Rückgabewerte ausgegeben werden. Dies ist möglicherweise auch nützlich, wenn By-Value-Strukturtypen mit langen Namen zurückgegeben werden.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    i := f.cached.locations[xx+0]
    j := f.cached.locations[xx+1]
    if j < i {
        try(errInvalidGlyphDataLength)
    }
    if j-i > maxGlyphDataLength {
        try(errUnsupportedGlyphDataLength)
    }
    buf, err = b.view(&f.src, int(i), int(j-i))
    return buf, i, j - i, err
}

Ich finde diesen Vorschlag auch gut.

Und ich habe eine Bitte.

Wie make können wir try erlauben, eine variable Anzahl von Parametern anzunehmen

• Versuch (f):
  wie oben.
  ein Rückgabefehlerwert ist obligatorisch (als letzter Rückgabeparameter).
  HÄUFIGSTES NUTZUNGSMODELL
• try(f, doPanic bool):
  wie oben, aber wenn doPanic, dann Panik(err) statt Rückkehr.
  In diesem Modus ist ein Rückgabefehlerwert nicht erforderlich.
• try(f, fn):
  wie oben, aber rufen Sie vor der Rückkehr fn(err) auf.
  In diesem Modus ist ein Rückgabefehlerwert nicht erforderlich.

Auf diese Weise ist es ein Built-in, das alle Anwendungsfälle verarbeiten kann, während es immer noch explizit ist. Seine Vorteile:

• immer explizit - keine Notwendigkeit, abzuleiten, ob in Panik geraten oder ein Fehler gesetzt und zurückgekehrt werden soll
• unterstützt kontextspezifische Handler (aber keine Handler-Kette)
• unterstützt Anwendungsfälle, in denen es keine Fehlerrückgabevariable gibt
• unterstützt must(...)-Semantik

Während wiederholtes if err !=nil { return ... err } sicherlich ein hässliches Stottern ist, bin ich damit einverstanden
die denken, dass der try()-Vorschlag sehr schlecht lesbar und etwas unausgesprochen ist.
Die Verwendung benannter Rückgaben ist ebenfalls problematisch.

Wenn diese Art des Aufräumens erforderlich ist, warum nicht try(err) als syntaktischer Zucker für
if err !=nil { return err } :

file, err := os.Open("file.go")
try(err)

zum

file, err := os.Open("file.go")
if err != nil {
   return err
}

Und wenn es mehr als einen Rückgabewert gibt, könnte try(err) return t1, ... tn, err sein
wobei t1, ... tn die Nullwerte der anderen Rückgabewerte sind.

Dieser Vorschlag kann die Notwendigkeit von benannten Rückgabewerten vermeiden und sein,
meiner Meinung nach verständlicher und besser lesbar.

Noch besser wäre meiner Meinung nach:

file, try(err) := os.Open("file.go")

Oder auch

file, err? := os.Open("file.go")

Letzteres ist abwärtskompatibel (? ist derzeit in Bezeichnern nicht zulässig).

(Dieser Vorschlag bezieht sich auf https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes. Aber die Beispiele für wiederkehrende Themen scheinen anders zu sein, da dies zu einem Zeitpunkt war, als ein explizites Handle noch diskutiert wurde, anstatt es zu verlassen das zu einer Verschiebung.)

Danke an das go-Team für diesen sorgfältigen, interessanten Vorschlag.

@rogpeppe kommentieren, wenn try den Stack-Frame automatisch hinzufügt, nicht ich, ich bin damit einverstanden, dass ich das Hinzufügen von Kontext entmutige.

@aarzilli - Ist also nach Ihrem Vorschlag eine Verzögerungsklausel jedes Mal obligatorisch, wenn wir tryf zusätzliche Parameter geben?

Was passiert, wenn ich es tue

try(ioutil.WriteFile(target, buf, 0644), "write file %s", target)

und keine defer-Funktion schreiben?

@Agnivade

Was passiert, wenn ich (...) eine Verzögerungsfunktion schreibe und nicht?

Typprüfungsfehler.

Meiner Meinung nach ist die Verwendung try , um das Ausschreiben aller Rückgabewerte zu vermeiden, eigentlich nur ein weiterer Schlag dagegen.

func (f *Font) viewGlyphData(b *Buffer, x GlyphIndex) (buf []byte, offset, length uint32, err error) {
    xx := int(x)
    if f.NumGlyphs() <= xx {
        try(ErrNotFound)
    }
    //...

Ich verstehe den Wunsch, return nil, 0, 0, ErrNotFound nicht ausschreiben zu müssen, aber ich würde das viel lieber auf andere Weise lösen.

Das Wort try bedeutet nicht „Rückkehr“. Und so wird es hier verwendet. Eigentlich würde ich es vorziehen, wenn sich der Vorschlag dahingehend ändert, dass try nicht direkt einen error annehmen kann, weil ich nie möchte, dass jemand solchen Code schreibt ^^ . Es liest sich falsch . Wenn Sie diesen Code einem Neuling zeigen würden, hätte er keine Ahnung, was dieser Versuch bewirkte.

Wenn wir eine Möglichkeit suchen, einfach nur Standardwerte und einen Fehlerwert zurückzugeben, lösen wir das separat. Vielleicht ein anderes eingebautes wie

return default(ErrNotFound)

Zumindest liest sich das mit einer Art Logik.

Aber missbrauchen wir try nicht, um ein anderes Problem zu lösen.

@natefinch Wenn das eingebaute try check wie im ursprünglichen Vorschlag check heißt, wäre es check(err) , was sich wesentlich besser liest, imo.

Abgesehen davon weiß ich nicht, ob es wirklich ein Missbrauch ist, try(err) zu schreiben. Es fällt sauber aus der Definition heraus. Das bedeutet aber andererseits auch, dass dies legal ist:

a, b := try(1, f(), err)

Ich denke, mein Hauptproblem mit try ist, dass es wirklich nur ein panic ist, das nur eine Ebene höher geht ... außer dass es im Gegensatz zu Panik ein Ausdruck ist, keine Aussage, also kannst du dich verstecken es mitten in einer Aussage irgendwo. Das macht es fast schlimmer als Panik.

@natefinch Wenn Sie es sich wie eine Panik vorstellen, die eine Ebene höher geht und dann andere Dinge tut, scheint es ziemlich chaotisch zu sein. Allerdings stelle ich mir das anders vor. Funktionen, die Fehler in Go zurückgeben, geben effektiv ein Ergebnis zurück, um sich locker an die Terminologie von Rust zu lehnen. try ist ein Dienstprogramm, das das Ergebnis entpackt und entweder ein "Fehlerergebnis" zurückgibt, wenn error != nil , oder den T-Teil des Ergebnisses entpackt, wenn error == nil .

Natürlich haben wir in Go eigentlich keine Ergebnisobjekte, aber es ist praktisch das gleiche Muster und try scheint eine natürliche Codierung dieses Musters zu sein. Ich glaube, dass jede Lösung für dieses Problem einige Aspekte der Fehlerbehandlung kodifizieren muss, und try s Lösung erscheint mir vernünftig. Ich selbst und andere schlagen vor, die Möglichkeiten von try etwas zu erweitern, um sie besser an bestehende Go-Fehlerbehandlungsmuster anzupassen, aber das zugrunde liegende Konzept bleibt dasselbe.

@ugorji Die von dir vorgeschlagene try(f, bool) -Variante klingt wie die must aus #32219.

@ugorji Die von dir vorgeschlagene try(f, bool) -Variante klingt wie die must aus #32219.

Ja, so ist es. Ich hatte einfach das Gefühl, dass alle 3 Fälle mit einer einzigen eingebauten Funktion behandelt werden könnten und alle Anwendungsfälle elegant erfüllen.

Da try() bereits magisch ist und den Fehlerrückgabewert kennt, könnte es erweitert werden, um auch einen Zeiger auf diesen Wert zurückzugeben, wenn es in der Nullargumentform aufgerufen wird? Das würde die Notwendigkeit benannter Rückgaben beseitigen, und ich glaube, es hilft, visuell zu korrelieren, woher der Fehler in defer-Anweisungen erwartet wird. Zum Beispiel:

func foo() error {
  defer fmt.HandleErrorf(try(), "important foo context info")
  try(bar())
  try(baz())
  try(etc())
}

@ugorji
Ich denke, der boolesche Wert auf try(f, bool) würde es schwer lesbar und leicht zu übersehen machen. Ich mag Ihren Vorschlag, aber für den Panikfall denke ich, dass dies für Benutzer weggelassen werden könnte, um dies in den Handler aus Ihrem dritten Aufzählungszeichen zu schreiben, z. B. try(f(), func(err error) { panic('at the disco'); }) , dies macht es für Benutzer deutlicher als ein verstecktes try(f(), true) das ist leicht zu übersehen, und ich denke nicht, dass die eingebauten Funktionen Panik auslösen sollten.

@ugorji
Ich denke, der boolesche Wert auf try(f, bool) würde es schwer lesbar und leicht zu übersehen machen. Ich mag Ihren Vorschlag, aber für den Panikfall denke ich, dass dies für Benutzer weggelassen werden könnte, um dies in den Handler aus Ihrem dritten Aufzählungszeichen zu schreiben, z. B. try(f(), func(err error) { panic('at the disco'); }) , dies macht es für Benutzer deutlicher als ein verstecktes try(f(), true) das ist leicht zu übersehen, und ich denke nicht, dass die eingebauten Funktionen Panik auslösen sollten.

Bei weiterem Nachdenken neige ich dazu, Ihrer Position und Ihrer Argumentation zuzustimmen, und es sieht immer noch elegant aus wie ein Einzeiler.

@patrick-nyt ist noch ein weiterer Befürworter der _Zuweisungssyntax_, um einen Nulltest auszulösen, in https://github.com/golang/go/issues/32437#issuecomment -499533464

Dieses Konzept erscheint in 13 separaten Antworten auf den Check/Handle-Vorschlag
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

f, ?return := os.Open(...)
f, ?panic  := os.Open(...)

Warum? Weil es sich wie Go 1 liest, während try() und check dies nicht tun.

https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md#draft -design

Ein Einwand gegen try scheint zu sein, dass es sich um einen Ausdruck handelt. Nehmen wir stattdessen an, dass es eine unäre Postfix-Anweisung ? gibt, die bedeutet, wenn nicht nil zurückgeben. Hier ist das Standardcodebeispiel (unter der Annahme, dass mein vorgeschlagenes zurückgestelltes Paket hinzugefügt wird):

func CopyFile(src, dst string) error {
    var err error // Don't need a named return because err is explicitly named
    defer deferred.Annotate(&err, "copy %s %s", src, dst)

    r, err := os.Open(src)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    w, err := os.Create(dst)
    err?
    defer deferred.AnnotatedExec(&err, r.Close)

    defer deferred.Cond(&err, func(){ os.Remove(dst) })
    _, err = io.Copy(w, r)

    return err
}

Das pgStore-Beispiel:

func (p *pgStore) DoWork() error {
    tx, err := p.handle.Begin()
    err?

    defer deferred.Cond(&err, func(){ tx.Rollback() })

    var res int64 
    err = tx.QueryRow(`INSERT INTO table (...) RETURNING c1`, ...).Scan(&res)
    // tricky bit: this would not change the value of err 
    // but the deferred.Cond would still be triggered by err being set before
    deferred.Format(err, "insert table")?

    _, err = tx.Exec(`INSERT INTO table2 (...) VALUES ($1)`, res)
    deferred.Format(err, "insert table2")?

    return tx.Commit()
}

Ich mag das von @jargv :

Da try() bereits magisch ist und den Fehlerrückgabewert kennt, könnte es erweitert werden, um auch einen Zeiger auf diesen Wert zurückzugeben, wenn es in der Nullargumentform aufgerufen wird? Das würde die Notwendigkeit benannter Rücksendungen beseitigen

Aber anstatt den Namen try basierend auf der Anzahl der Argumente zu überladen, könnte meiner Meinung nach eine andere Magie eingebaut sein, sagen wir reterr oder so.

Ich habe einige sehr häufig verwendete Pakete durchgesehen und nach Go-Code gesucht, der unter Fehlerbehandlung "leidet", aber vor dem Schreiben gut durchdacht worden sein muss, um herauszufinden, welche "Magie" das vorgeschlagene try() bewirken würde.
Wenn ich den Vorschlag nicht missverstanden habe, würden derzeit viele davon (z. B. nicht sehr einfache Fehlerbehandlung) nicht viel gewinnen oder müssten beim "alten" Fehlerbehandlungsstil bleiben.
Beispiel von net/http/request.go:

func (r *Request) write(w io.Writer, usingProxy bool, extraHeaders Header, waitForContinue func() bool) (err error) {
`

trace := httptrace.ContextClientTrace(r.Context())
if trace != nil && trace.WroteRequest != nil {
    defer func() {
        trace.WroteRequest(httptrace.WroteRequestInfo{
            Err: err,
        })
    }()
}

// Find the target host. Prefer the Host: header, but if that
// is not given, use the host from the request URL.
//
// Clean the host, in case it arrives with unexpected stuff in it.
host := cleanHost(r.Host)
if host == "" {
    if r.URL == nil {
        return errMissingHost
    }
    host = cleanHost(r.URL.Host)
}

// According to RFC 6874, an HTTP client, proxy, or other
// intermediary must remove any IPv6 zone identifier attached
// to an outgoing URI.
host = removeZone(host)

ruri := r.URL.RequestURI()
if usingProxy && r.URL.Scheme != "" && r.URL.Opaque == "" {
    ruri = r.URL.Scheme + "://" + host + ruri
} else if r.Method == "CONNECT" && r.URL.Path == "" {
    // CONNECT requests normally give just the host and port, not a full URL.
    ruri = host
    if r.URL.Opaque != "" {
        ruri = r.URL.Opaque
    }
}
if stringContainsCTLByte(ruri) {
    return errors.New("net/http: can't write control character in Request.URL")
}
// TODO: validate r.Method too? At least it's less likely to
// come from an attacker (more likely to be a constant in
// code).

// Wrap the writer in a bufio Writer if it's not already buffered.
// Don't always call NewWriter, as that forces a bytes.Buffer
// and other small bufio Writers to have a minimum 4k buffer
// size.
var bw *bufio.Writer
if _, ok := w.(io.ByteWriter); !ok {
    bw = bufio.NewWriter(w)
    w = bw
}

_, err = fmt.Fprintf(w, "%s %s HTTP/1.1\r\n", valueOrDefault(r.Method, "GET"), ruri)
if err != nil {
    return err
}

// Header lines
_, err = fmt.Fprintf(w, "Host: %s\r\n", host)
if err != nil {
    return err
}
if trace != nil && trace.WroteHeaderField != nil {
    trace.WroteHeaderField("Host", []string{host})
}

// Use the defaultUserAgent unless the Header contains one, which
// may be blank to not send the header.
userAgent := defaultUserAgent
if r.Header.has("User-Agent") {
    userAgent = r.Header.Get("User-Agent")
}
if userAgent != "" {
    _, err = fmt.Fprintf(w, "User-Agent: %s\r\n", userAgent)
    if err != nil {
        return err
    }
    if trace != nil && trace.WroteHeaderField != nil {
        trace.WroteHeaderField("User-Agent", []string{userAgent})
    }
}

// Process Body,ContentLength,Close,Trailer
tw, err := newTransferWriter(r)
if err != nil {
    return err
}
err = tw.writeHeader(w, trace)
if err != nil {
    return err
}

err = r.Header.writeSubset(w, reqWriteExcludeHeader, trace)
if err != nil {
    return err
}

if extraHeaders != nil {
    err = extraHeaders.write(w, trace)
    if err != nil {
        return err
    }
}

_, err = io.WriteString(w, "\r\n")
if err != nil {
    return err
}

if trace != nil && trace.WroteHeaders != nil {
    trace.WroteHeaders()
}

// Flush and wait for 100-continue if expected.
if waitForContinue != nil {
    if bw, ok := w.(*bufio.Writer); ok {
        err = bw.Flush()
        if err != nil {
            return err
        }
    }
    if trace != nil && trace.Wait100Continue != nil {
        trace.Wait100Continue()
    }
    if !waitForContinue() {
        r.closeBody()
        return nil
    }
}

if bw, ok := w.(*bufio.Writer); ok && tw.FlushHeaders {
    if err := bw.Flush(); err != nil {
        return err
    }
}

// Write body and trailer
err = tw.writeBody(w)
if err != nil {
    if tw.bodyReadError == err {
        err = requestBodyReadError{err}
    }
    return err
}

if bw != nil {
    return bw.Flush()
}
return nil

}
`

oder wie in einem gründlichen Test wie pprof/profile/profile_test.go verwendet:
`
func checkAggregation(prof *Profile, a *aggTest) error {
// Überprüfen Sie, ob die Gesamtzahl der Stichproben für die Zeilen beibehalten wurde.
gesamt := int64(0)

samples := make(map[string]bool)
for _, sample := range prof.Sample {
    tb := locationHash(sample)
    samples[tb] = true
    total += sample.Value[0]
}

if total != totalSamples {
    return fmt.Errorf("sample total %d, want %d", total, totalSamples)
}

// Check the number of unique sample locations
if a.rows != len(samples) {
    return fmt.Errorf("number of samples %d, want %d", len(samples), a.rows)
}

// Check that all mappings have the right detail flags.
for _, m := range prof.Mapping {
    if m.HasFunctions != a.function {
        return fmt.Errorf("unexpected mapping.HasFunctions %v, want %v", m.HasFunctions, a.function)
    }
    if m.HasFilenames != a.fileline {
        return fmt.Errorf("unexpected mapping.HasFilenames %v, want %v", m.HasFilenames, a.fileline)
    }
    if m.HasLineNumbers != a.fileline {
        return fmt.Errorf("unexpected mapping.HasLineNumbers %v, want %v", m.HasLineNumbers, a.fileline)
    }
    if m.HasInlineFrames != a.inlineFrame {
        return fmt.Errorf("unexpected mapping.HasInlineFrames %v, want %v", m.HasInlineFrames, a.inlineFrame)
    }
}

// Check that aggregation has removed finer resolution data.
for _, l := range prof.Location {
    if !a.inlineFrame && len(l.Line) > 1 {
        return fmt.Errorf("found %d lines on location %d, want 1", len(l.Line), l.ID)
    }

    for _, ln := range l.Line {
        if !a.fileline && (ln.Function.Filename != "" || ln.Line != 0) {
            return fmt.Errorf("found line %s:%d on location %d, want :0",
                ln.Function.Filename, ln.Line, l.ID)
        }
        if !a.function && (ln.Function.Name != "") {
            return fmt.Errorf(`found file %s location %d, want ""`,
                ln.Function.Name, l.ID)
        }
    }
}

return nil

}
`
Dies sind zwei Beispiele, die mir einfallen, in denen man sagen würde: "Ich hätte gerne eine bessere Fehlerbehandlungsoption"

Kann jemand demonstrieren, wie sich diese mit try() verbessern würden?

Ich bin überwiegend für diesen Vorschlag.

Mein Hauptanliegen, das ich mit vielen Kommentatoren teile, betrifft benannte Ergebnisparameter. Der aktuelle Vorschlag ermutigt sicherlich zu einer viel stärkeren Verwendung von benannten Ergebnisparametern, und ich denke, das wäre ein Fehler. Ich glaube nicht, dass dies einfach eine Frage des Stils ist, wie der Vorschlag besagt: Benannte Ergebnisse sind ein subtiles Merkmal der Sprache, das den Code in vielen Fällen fehleranfälliger oder weniger klar macht. Nach ~8 Jahren des Lesens und Schreibens von Go-Code verwende ich wirklich nur benannte Ergebnisparameter für zwei Zwecke:

• Dokumentation der Ergebnisparameter
• Manipulieren eines Ergebniswerts (normalerweise ein error ) innerhalb einer Zurückstellung

Um dieses Problem aus einer neuen Richtung anzugreifen, hier ist eine Idee, die meiner Meinung nach nicht eng mit irgendetwas übereinstimmt, das im Designdokument oder in diesem Kommentarthread zu diesem Thema besprochen wurde. Nennen wir es "Error-Defers":

Ermöglicht die Verwendung von defer zum Aufrufen von Funktionen mit einem impliziten Fehlerparameter.

Also, wenn Sie eine Funktion haben

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

Dann wird in einer Funktion g , in der der letzte Ergebnisparameter den Typ error hat (dh jede Funktion, in der try verwendet werden kann), ein Aufruf von f können wie folgt verschoben werden:

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

Die Semantik von error-defer ist:

1. Der verzögerte Aufruf von f wird mit dem letzten Ergebnisparameter von g als erstem Eingabeparameter von f aufgerufen
2. f wird nur aufgerufen, wenn dieser Fehler nicht null ist
3. Das Ergebnis von f wird dem letzten Ergebnisparameter von g zugewiesen

Um also ein Beispiel aus dem alten Dokument zum Fehlerbehandlungsdesign zu verwenden, könnten wir dies tun, indem wir error-defer and try verwenden

func printSum(a, b string) error {
    defer func(err error) error {
        return fmt.Errorf("printSum(%q + %q): %v", a, b, err)
    }()
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

So würde HandleErrorf funktionieren:

func printSum(a, b string) error {
    defer handleErrorf("printSum(%q + %q)", a, b)
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x+y)
    return nil
}

func handleErrorf(err error, format string, args ...interface{}) error {
    return fmt.Errorf(format+": %v", append(args, err)...)
}

Ein Eckfall, der ausgearbeitet werden müsste, ist der Umgang mit Fällen, in denen nicht eindeutig ist, welche Form der Verzögerung wir verwenden. Ich denke, das passiert nur mit (sehr ungewöhnlichen) Funktionen mit Signaturen wie dieser:

func(error, ...error) error

Es scheint vernünftig zu sagen, dass dieser Fall auf die nicht fehlerverzögernde Weise behandelt wird (und dies die Abwärtskompatibilität bewahrt).

Wenn man in den letzten Tagen über diese Idee nachdenkt, ist sie ein bisschen magisch, aber die Vermeidung von benannten Ergebnisparametern ist ein großer Vorteil zu ihren Gunsten. Da try zu einer stärkeren Verwendung von defer zur Fehlermanipulation anregt, macht es Sinn, dass defer erweitert werden könnte, um es besser für diesen Zweck geeignet zu machen. Außerdem gibt es eine gewisse Symmetrie zwischen try und error-defer.

Schließlich sind Error-Defer heute sogar ohne try nützlich, da sie die Verwendung von benannten Ergebnisparametern zur Manipulation von Fehlerrückgaben ersetzen. Hier ist zum Beispiel eine bearbeitete Version von echtem Code:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) (_ []*File, err error) {
    files := make([]*file, len(keys))

    defer func() {
        if err != nil {
            // Return any successfully retrieved files.
            for _, f := range files {
                if f != nil {
                    c.put(f)
                }
            }
        }
    }()

    // ...
}

Mit error-defer wird dies zu:

// GetMulti retrieves multiple files through the cache at once and returns its
// results as a slice parallel to the input.
func (c *FileCache) GetMulti(keys []string) ([]*File, error) {
    files := make([]*file, len(keys))

    defer func(err error) error {
        // Return any successfully retrieved files.
        for _, f := range files {
            if f != nil {
                c.put(f)
            }
        }
        return err
    }()

    // ...
}

@beoran In Bezug auf Ihren Kommentar , dass wir auf Generika warten sollten. Generika helfen hier nicht - lesen Sie bitte die FAQ .

In Bezug auf Ihre Vorschläge zum 2-Argument-Standardverhalten von @velovix von try : Wie ich bereits sagte, ist Ihre Vorstellung davon, was die offensichtlich vernünftige Wahl ist, der Alptraum von jemand anderem.

Darf ich vorschlagen, dass wir diese Diskussion fortsetzen, sobald sich ein breiter Konsens entwickelt hat, dass try mit einer expliziten Fehlerbehandlungsroutine eine bessere Idee ist als das aktuelle minimale try . An dieser Stelle ist es sinnvoll, die Feinheiten eines solchen Designs zu diskutieren.

(Eigentlich mag ich es, einen Handler zu haben. Das ist einer unserer früheren Vorschläge. Und wenn wir try so übernehmen, wie es ist, können wir uns immer noch auf ein try mit einem Handler in einem Stürmer zubewegen -kompatibler Weg - zumindest wenn der Handler optional ist. Aber gehen wir einen Schritt nach dem anderen vor.)

@aarzilli Danke für deinen Vorschlag .

Solange Dekorationsfehler optional sind, werden die Leute dazu neigen, es nicht zu tun (es ist immerhin zusätzliche Arbeit). Siehe auch meinen Kommentar hier .

Ich glaube also nicht, dass das vorgeschlagene try die Leute davon abhält, Fehler zu dekorieren (sie sind aus dem oben genannten Grund bereits mit dem if entmutigt); es ist, dass try es nicht _ermutigt_.

(Eine Möglichkeit, dies zu fördern, besteht darin, es in try : Man kann try nur verwenden, wenn man auch den Fehler schmückt oder ausdrücklich ablehnt.)

Aber zurück zu Ihren Vorschlägen: Ich glaube, Sie führen hier noch viel mehr Maschinen ein. Die Semantik von defer zu ändern, nur damit es für try besser funktioniert, ist nichts, was wir in Betracht ziehen möchten, es sei denn, diese defer -Änderungen sind auf allgemeinere Weise von Vorteil. Außerdem bindet Ihr Vorschlag defer mit try zusammen und macht somit diese beiden Mechanismen weniger orthogonal; etwas, das wir vermeiden möchten.

Aber was noch wichtiger ist, ich bezweifle, dass Sie alle zwingen wollen, defer zu schreiben, nur damit sie try verwenden können. Aber ohne dies zu tun, sind wir wieder am Anfang: Die Leute werden dazu neigen, Fehler nicht zu schmücken.

(Ich mag es übrigens, einen Handler zu haben. Das ist einer unserer früheren Vorschläge. Und wenn wir try so übernehmen, wie es ist, können wir immer noch auf vorwärtskompatible Weise zu einem try mit einem Handler übergehen - zumindest wenn der Handler es ist optional. Aber gehen wir einen Schritt nach dem anderen vor.)

Sicher, vielleicht ist ein mehrstufiger Ansatz der richtige Weg. Wenn wir in Zukunft ein optionales Handler-Argument hinzufügen, könnten Tools erstellt werden, die den Autor vor einem nicht behandelten try im gleichen Sinne wie das errcheck -Tool warnen. Unabhängig davon freue ich mich über Ihr Feedback!

@alanfo Vielen Dank für Ihr positives Feedback .

Zu den von Ihnen angesprochenen Punkten:

1) Wenn das einzige Problem mit try die Tatsache ist, dass man eine Fehlerrückgabe benennen muss, damit wir einen Fehler über defer schmücken können, denke ich, dass wir gut sind. Wenn sich herausstellt, dass die Benennung des Ergebnisses ein echtes Problem darstellt, könnten wir es ansprechen. Ein einfacher Mechanismus, den ich mir vorstellen kann, wäre eine vordeklarierte Variable, die ein Alias ​​für ein Fehlerergebnis ist (stellen Sie sich vor, sie enthält den Fehler, der das letzte try ausgelöst hat). Vielleicht gibt es bessere Ideen. Wir haben dies nicht vorgeschlagen, weil es bereits einen Mechanismus in der Sprache gibt, der das Ergebnis benennen soll.
2) try und Testen: Dies kann angegangen und zum Laufen gebracht werden. Siehe ausführliches Dokument.
3) Dies wird explizit in der ausführlichen Dok. angesprochen.
4) Bestätigt.

@benhoyt Vielen Dank für Ihr positives Feedback .

Wenn das Hauptargument gegen diesen Vorschlag die Tatsache ist, dass try eingebaut ist, sind wir in einer großartigen Lage. Die Verwendung eines integrierten ist einfach eine pragmatische Lösung für das Abwärtskompatibilitätsproblem (es verursacht zufällig keine zusätzliche Arbeit für den Parser und die Tools usw. - aber das ist nur ein netter Nebeneffekt, nicht der Hauptgrund). Es gibt auch einige Vorteile, Klammern schreiben zu müssen, dies wird im Design-Dokument (Abschnitt über Eigenschaften des vorgeschlagenen Designs) ausführlich besprochen.

Alles in allem sollten wir das Schlüsselwort try in Betracht ziehen, wenn die Verwendung eines integrierten Schlüsselworts der Showstopper ist. Es ist jedoch nicht abwärtskompatibel mit vorhandenem Code, da das Schlüsselwort mit vorhandenen Bezeichnern in Konflikt geraten kann.

(Um vollständig zu sein, gibt es auch die Option eines Operators wie ? , der abwärtskompatibel wäre. Für eine Sprache wie Go scheint es mir jedoch nicht die beste Wahl zu sein. Aber noch einmal, Wenn das alles ist, was es braucht, um try schmackhaft zu machen, sollten wir es vielleicht in Betracht ziehen.)

@ugorji Danke für dein positives Feedback .

try könnte um ein zusätzliches Argument erweitert werden. Unsere Präferenz wäre, nur eine Funktion mit der Signatur func (error) error zu nehmen. Wenn Sie in Panik geraten möchten, ist es einfach, eine einzeilige Hilfsfunktion bereitzustellen:

func doPanic(err error) error { panic(err) }

Es ist besser, das Design von try einfach zu halten.

@patrick-nyt Was Sie vorschlagen :

file, err := os.Open("file.go")
try(err)

wird mit dem aktuellen Vorschlag möglich sein.

@dpinela , @ugorji Bitte lesen Sie auch das Design-Dokument zum Thema must vs. try . Es ist besser, try so einfach wie möglich zu halten. must ist ein häufiges „Muster“ in Initialisierungsausdrücken, aber es besteht keine dringende Notwendigkeit, das zu „korrigieren“.

@jargv Danke für deinen Vorschlag . Das ist eine interessante Idee (siehe auch meinen Kommentar hier zu diesem Thema). Zusammenfassen:

• try(x) funktioniert wie vorgeschlagen
• try() gibt ein *error zurück, das auf das Fehlerergebnis zeigt

Dies wäre in der Tat ein weiterer Weg, um zum Ergebnis zu gelangen, ohne es benennen zu müssen.

@cespare Der Vorschlag von @jargv sieht für mich viel einfacher aus als das, was Sie vorschlagen . Es löst das gleiche Problem des Zugriffs auf den Ergebnisfehler. Was denken Sie?

Gemäß https://github.com/golang/go/issues/32437#issuecomment -499320588:

func doPanic(err Fehler) Fehler { Panik(err) }

Ich gehe davon aus, dass diese Funktion ziemlich häufig sein wird. Könnte dies in "Builtin" (oder irgendwo anders in einem Standardpaket, zB errors ) vordefiniert sein?

Schade, dass Sie Generika nicht mächtig genug erwarten, um sie umzusetzen
ausprobieren, ich hätte eigentlich gehofft, dass es geht.

Ja, dieser Vorschlag könnte ein erster Schritt sein, obwohl ich darin keinen großen Nutzen sehe
es selbst, wie es jetzt steht.

Zugegeben, diese Ausgabe konzentriert sich vielleicht zu sehr auf detaillierte Alternativen,
aber es zeigt sich, dass viele Teilnehmer damit nicht ganz zufrieden sind
es. Was zu fehlen scheint, ist ein breiter Konsens über diesen Vorschlag...

Op vr 7. Juni 2019 01:04 schreef pj [email protected] :

Asper #32437 (Kommentar)
https://github.com/golang/go/issues/32437#issuecomment-499320588 :

func doPanic(err Fehler) Fehler { Panik(err) }

Ich gehe davon aus, dass diese Funktion ziemlich häufig sein wird. Könnte dies vordefiniert sein
in "eingebaut"?

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEMYZY#issuecomment-49969 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

@pjebs , ich habe die entsprechende Funktion Dutzende Male geschrieben. Ich nenne es normalerweise „orDie“ oder „check“. Es ist so einfach, dass es nicht wirklich notwendig ist, es in die Standardbibliothek aufzunehmen. Außerdem möchten verschiedene Personen möglicherweise eine Protokollierung oder was auch immer vor der Beendigung.

@beoran Vielleicht könnten Sie die Verbindung zwischen Generika und Fehlerbehandlung erweitern. Wenn ich an sie denke, scheinen sie zwei verschiedene Dinge zu sein. Generika sind kein Allheilmittel, das alle Probleme mit der Sprache lösen kann. Es ist die Fähigkeit, eine einzelne Funktion zu schreiben, die auf mehreren Typen ausgeführt werden kann.

Dieser spezifische Fehlerbehandlungsvorschlag versucht, Boilerplate zu reduzieren, indem eine vordeklarierte Funktion try eingeführt wird, die die Flusskontrolle unter bestimmten Umständen ändert. Generika werden niemals den Kontrollfluss verändern. Also ich sehe den Zusammenhang nicht wirklich.

Meine erste Reaktion darauf war ein 👎, da ich mir vorgestellt hatte, dass die Behandlung mehrerer fehleranfälliger Aufrufe innerhalb einer Funktion die defer -Fehlerbehandlung verwirrend machen würde. Nachdem ich den ganzen Vorschlag durchgelesen habe, habe ich meine Reaktion auf ein ❤️ und 👍 umgedreht, da ich erfahren habe, dass dies immer noch mit relativ geringer Komplexität erreicht werden kann.

@carlmjohnson Ja, es ist einfach, aber ...

Ich habe die äquivalente Funktion dutzende Male geschrieben.

Die Vorteile einer vordefinierten Funktion sind:

1. Wir können es einzeilig machen
2. Wir müssen die err => panic-Funktion nicht in jedem Paket, das wir verwenden, neu deklarieren oder einen gemeinsamen Speicherort dafür pflegen. Da es wahrscheinlich jedem in der Go-Community gemeinsam ist, ist das "Standardpaket" _ der _ übliche Speicherort dafür.

@griesemer Mit der Error-Handler-Variante des ursprünglichen Versuchsvorschlags ist die Anforderung der übergreifenden Funktion zum Zurückgeben von Fehlern jetzt nicht mehr erforderlich.

Als ich mich zum ersten Mal danach erkundigte, wurde ich darauf hingewiesen, dass der Vorschlag es zwar berücksichtigt, aber (aus gutem Grund) für zu gefährlich hielt. Aber wenn wir try() ohne eine Fehlerbehandlungsroutine in einem Szenario verwenden, in dem die übergreifende Funktion keinen Fehler zurückgibt, werden durch die Umwandlung in einen Kompilierzeitfehler die im Vorschlag diskutierten Bedenken gemildert

@pjebs Die Anforderung der übergreifenden Funktion, einen Fehler zurückzugeben, war im ursprünglichen Design nicht erforderlich, _wenn_ ein Fehlerhandler bereitgestellt wurde. Aber es ist nur eine weitere Komplikation von try . Es ist _viel_ besser, es einfach zu halten. Stattdessen wäre es klarer, eine separate must -Funktion zu haben, die bei einem Fehler immer in Panik gerät (aber ansonsten wie try ist). Dann ist es offensichtlich, was im Code passiert und man muss nicht auf den Kontext schauen.

Die Hauptattraktion eines solchen must wäre, dass es mit Unit-Tests verwendet werden könnte; besonders wenn das testing -Paket geeignet angepasst wurde, um sich von den durch must verursachten Paniken zu erholen und sie auf nette Weise als Testfehler zu melden. Aber warum noch einen weiteren neuen Sprachmechanismus hinzufügen, wenn wir das Testpaket einfach so anpassen können, dass es auch Testfunktionen der Form TestXxx(t *testing.T) error akzeptiert? Wenn sie einen Fehler zurückgeben, was doch ganz natürlich erscheint (vielleicht hätten wir das von Anfang an tun sollen), dann wird try gut funktionieren. Lokale Tests erfordern etwas mehr Arbeit, sind aber wahrscheinlich machbar.

Die andere relativ häufige Verwendung für must ist in globalen Initialisierungsausdrücken ( must(regexp.Compile... usw.). If wäre ein "nice to have", aber das hebt es nicht unbedingt auf das Niveau, das für ein neues Sprachfeature erforderlich ist.

@griesemer Angesichts der Tatsache, dass must vage mit try verwandt ist, und angesichts der Tatsache, dass die Dynamik dahin geht, dass try implementiert wird, denken Sie nicht, dass es gut ist, must in Betracht zu ziehen

Die Chancen stehen gut, dass es, wenn es in dieser Runde nicht diskutiert wird, einfach nicht implementiert/ernsthaft in Betracht gezogen wird, zumindest für mehr als 3 Jahre (oder vielleicht überhaupt). Die Diskussionsüberschneidung wäre auch gut, anstatt bei Null anzufangen und Diskussionen zu recyceln.

Viele Leute haben gesagt, dass must try passt.

@pjebs Es sieht ganz sicher nicht so aus, als gäbe es im Moment eine „Dynamik zur Implementierung try “ … – Und wir haben das auch erst vor zwei Tagen gepostet. Es ist auch nichts entschieden. Geben wir dem etwas Zeit.

Es ist uns nicht entgangen, dass must gut zu try , aber das ist nicht dasselbe, als würde es Teil der Sprache werden. Wir haben erst begonnen, diesen Raum mit einer größeren Gruppe von Menschen zu erkunden. Wir wissen wirklich noch nicht, was dafür oder dagegen sprechen könnte. Danke.

Nachdem ich Stunden damit verbracht hatte, alle Kommentare und das detaillierte Designdokument zu lesen, wollte ich diesem Vorschlag meine Ansichten hinzufügen.

Ich werde mein Bestes tun, um die Bitte von @ianlancetaylor zu respektieren, vorherige Punkte nicht nur zu wiederholen, sondern stattdessen neue Kommentare zur Diskussion hinzuzufügen. Ich glaube jedoch nicht, dass ich die neuen Kommentare machen kann, ohne mich auf frühere Kommentare zu beziehen.

Bedenken

Unglückliche Überladung von defer

Die Vorliebe, die offensichtliche und unkomplizierte Natur von defer als alarmierend zu überladen. Wenn ich defer closeFile(f) schreibe, ist das für mich direkt und offensichtlich, was passiert und warum; am Ende der Funktion, die aufgerufen wird. Und während die Verwendung defer für panic() und recover() weniger offensichtlich ist, verwende ich es selten, wenn überhaupt, und sehe es fast nie, wenn ich den Code anderer lese.

Spoo defer zu überladen, um auch Fehler zu behandeln, ist nicht offensichtlich und verwirrend. Warum das Schlüsselwort defer ? Bedeutet defer nicht _"Später erledigen"_ statt _"Vielleicht später?"_

Außerdem gibt es die Bedenken des Go-Teams bezüglich der Leistung von defer . Angesichts dessen erscheint es doppelt unglücklich, dass defer für den _„heißen Pfad“_-Codefluss in Betracht gezogen wird.

Keine Statistiken, die einen signifikanten Anwendungsfall bestätigen

Wie von @prologic erwähnt, basiert dieser try() -Vorschlag auf einem großen Prozentsatz von Code, der diesen Anwendungsfall verwenden würde, oder basiert er stattdessen auf dem Versuch, diejenigen zu besänftigen, die sich über die Go-Fehlerbehandlung beschwert haben?

Ich wünschte, ich wüsste, wie ich Ihnen Statistiken aus meiner Codebasis geben kann, ohne jede Datei erschöpfend zu überprüfen und Notizen zu machen. Ich weiß nicht, wie @prologic in der Lage war, froh zu sein, dass er es getan hat.

Aber anekdotisch wäre ich überrascht, wenn try() 5 % meiner Anwendungsfälle ansprechen würde, und ich würde vermuten, dass es weniger als 1 % ansprechen würde. Wissen Sie sicher, dass andere sehr unterschiedliche Ergebnisse haben? Haben Sie eine Teilmenge der Standardbibliothek genommen und versucht zu sehen, wie sie angewendet werden würde?

Denn ohne bekannte Statistiken, dass dies für eine große Menge Code in freier Wildbahn angemessen ist, muss ich fragen, ob diese neue komplizierte Änderung der Sprache, die von jedem verlangen wird, die neuen Konzepte zu lernen, wirklich eine überzeugende Anzahl von Anwendungsfällen anspricht?

Erleichtert Entwicklern das Ignorieren von Fehlern

Dies ist eine totale Wiederholung dessen, was andere kommentiert haben, aber was im Grunde try() liefert, ist in vielerlei Hinsicht analog dazu, das Folgende einfach als idomatischen Code zu umarmen, und dies ist Code, der niemals seinen Weg in irgendeinen Code finden wird - Respektieren von Entwicklerschiffen:

f, _ := os.Open(filename)

Ich weiß, dass ich in meinem eigenen Code besser sein kann, aber ich weiß auch, dass viele von uns auf die Größe anderer Go-Entwickler angewiesen sind, die einige enorm nützliche Pakete veröffentlichen, aber nach dem, was ich in _"Other People's Code(tm)"_ gesehen habe Best Practices bei der Fehlerbehandlung werden oft ignoriert.

Also im Ernst, wollen wir es Entwicklern wirklich erleichtern, Fehler zu ignorieren und ihnen erlauben, GitHub mit nicht robusten Paketen zu verschmutzen?

Kann (meistens) bereits try() im Userland implementieren

Sofern ich den Vorschlag nicht falsch verstehe – was ich wahrscheinlich tue – ist hier try() im Go Playground implementiert in userland , allerdings mit nur einem (1) Rückgabewert und Rückgabe einer Schnittstelle anstelle des erwarteten Typs:

package main

import (
    "errors"
    "fmt"
    "strings"
)
func main() {
    defer func() {
        r := recover()
        if r != nil && strings.HasPrefix(r.(string),"TRY:") {
            fmt.Printf("Ouch! %s",strings.TrimPrefix(r.(string),"TRY: "))
        }
    }()
    n := try(badjuju()).(int)
    fmt.Printf("Just chillin %dx!",n)   
}
func badjuju() (int,error) {
    return 10, errors.New("this is a really bad error")
}
func try(args ...interface{}) interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0]
}

Der Benutzer könnte also try2() , try3() usw. hinzufügen, je nachdem, wie viele Rückgabewerte er zurückgeben muss.

Aber Go würde nur eine (1) einfache _ und doch universelle _ Sprachfunktion benötigen, um Benutzern, die try() wollen, zu ermöglichen, ihre eigene Unterstützung zu rollen, wenn auch eine, die immer noch eine explizite Typenzusicherung erfordert. Fügen Sie eine _(vollständig abwärtskompatibel)_-Fähigkeit für ein Go func hinzu, um eine unterschiedliche Anzahl von Rückgabewerten zurückzugeben, z.

func try(args ...interface{}) ...interface{} {
    err,ok := args[1].(error)
    if ok && err != nil {
        panic(fmt.Sprintf("TRY: %s",err.Error()))
    }
    return args[0:len(args)-2]
}

Und wenn Sie sich zuerst mit Generika befassen, wären die Typzusicherungen nicht einmal erforderlich _(obwohl ich denke, dass die Anwendungsfälle für Generika reduziert werden sollten, indem Sie integrierte Funktionen hinzufügen, um die Anwendungsfälle von Generika zu adressieren, anstatt den verwirrenden Semantik- und Syntaxsalat von Generika hinzuzufügen von Java et al.)_

Mangelnde Offensichtlichkeit

Beim Studium des Codes des Vorschlags finde ich, dass das Verhalten nicht offensichtlich und etwas schwer zu begründen ist.

Wenn ich sehe, dass try() einen Ausdruck umschließt, was passiert, wenn ein Fehler zurückgegeben wird?

Wird der Fehler einfach ignoriert? Oder springt es zum ersten oder letzten defer , und wenn ja, setzt es automatisch eine Variable namens err innerhalb des Abschlusses, oder übergibt es als Parameter _(I sehe keinen Parameter?)_. Und wenn kein automatischer Fehlername, wie benenne ich ihn? Und bedeutet das, dass ich meine eigene Variable err in meiner Funktion nicht deklarieren kann, um Konflikte zu vermeiden?

Und wird es alle defer s anrufen? In umgekehrter Reihenfolge oder in normaler Reihenfolge?

Oder wird es sowohl von der Schließung als auch von func zurückkehren, wo der Fehler zurückgegeben wurde? _(Etwas, an das ich nie gedacht hätte, wenn ich hier nicht Worte gelesen hätte, die das implizieren.)_

Nachdem ich den Vorschlag und alle bisherigen Kommentare gelesen habe, kenne ich die Antworten auf die obigen Fragen ehrlich gesagt immer noch nicht. Ist das die Art von Feature, die wir einer Sprache hinzufügen möchten, deren Befürworter sich dafür einsetzen, _"Captain Obvious"_ zu sein?

Mangelnde Kontrolle

Bei Verwendung defer scheint es, als wäre die einzige Kontrolle, die Entwicklern gewährt würde, die Verzweigung zu _(dem neuesten?)_ defer . Aber meiner Erfahrung nach ist es mit allen Methoden, die über ein triviales func hinausgehen, normalerweise komplizierter.

Oft habe ich es als hilfreich empfunden, Aspekte der Fehlerbehandlung innerhalb eines func – oder sogar über package hinweg – zu teilen, aber dann auch eine spezifischere Behandlung zu haben, die von einem oder mehreren anderen Paketen geteilt wird.

Zum Beispiel kann ich fünf (5) func Aufrufe aufrufen, die ein error() aus einem anderen func zurückgeben; nennen wir sie A() , B() , C() , D() und E() . Möglicherweise brauche ich C() , um eine eigene Fehlerbehandlung zu haben, A() , B() , D() und E() , um einige Fehlerbehandlungen zu teilen. und B() und E() , um eine spezifische Behandlung zu haben.

Aber ich glaube nicht, dass dies mit diesem Vorschlag möglich wäre. Zumindest nicht leicht.

Ironischerweise verfügt Go jedoch bereits über Sprachfunktionen, die ein hohes Maß an Flexibilität ermöglichen, die nicht auf eine kleine Menge von Anwendungsfällen beschränkt sein muss; func s und Schließungen. Daher meine rhetorische Frage:

_ "Warum können wir nicht einfach geringfügige Verbesserungen zur bestehenden Sprache hinzufügen, um diese Anwendungsfälle zu adressieren, und müssen keine neuen integrierten Funktionen hinzufügen oder verwirrende Semantik akzeptieren?" _

Es handelt sich um eine rhetorische Frage, da ich beabsichtige, als Alternative einen Vorschlag vorzulegen, den ich mir während des Studiums dieses Vorschlags und unter Berücksichtigung aller seiner Nachteile ausgedacht habe.

Aber ich schweife ab, das kommt später, und in diesem Kommentar geht es darum, warum der aktuelle Vorschlag überdacht werden muss.

Fehlende angegebene Unterstützung für break

Dies mag sich anfühlen, als käme es aus dem linken Feld, da die meisten Leute frühe Rückgaben für die Fehlerbehandlung verwenden, aber ich habe festgestellt, dass es vorzuziehen ist, break für die Fehlerbehandlung zu verwenden, die den größten Teil oder die gesamte Funktion vor return umschließt

Ich habe diesen Ansatz eine Zeit lang verwendet, und seine Vorteile allein durch die Erleichterung des Refactorings machen ihn dem frühen return vorzuziehen, aber er hat mehrere andere Vorteile, darunter einen einzigen Austrittspunkt und die Möglichkeit, einen Abschnitt einer Funktion vorzeitig zu beenden, aber immer noch zu sein in der Lage, eine Bereinigung auszuführen _(was wahrscheinlich der Grund ist, warum ich defer so selten verwende, was ich in Bezug auf den Programmablauf schwerer zu begründen finde.)_

Um break anstelle einer vorzeitigen Rückkehr zu verwenden, verwenden Sie eine for range "1" {...} -Schleife, um einen Block für die Unterbrechung zum Verlassen von _ zu erstellen (ich erstelle tatsächlich ein Paket namens only , das nur eine Konstante enthält namens Once mit einem Wert von "1" ):_

func (me *Config) WriteFile() (err error) {
    for range only.Once {
        var j []byte
        j, err = json.MarshalIndent(me, "", "    ")
        if err != nil {
            err = fmt.Errorf("unable to marshal config; %s", 
                err.Error(),
            )
            break
        }
        err = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to make directory'%s'; %s", 
                me.GetDir(), 
                err.Error(),
            )
            break
        }
        err = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if err != nil {
            err = fmt.Errorf("unable to write to config file '%s'; %s", 
                me.GetFilepath(), 
                err.Error(),
            )
            break
        }
    }
    return err
}

Ich habe vor, in naher Zukunft ausführlich über das Muster zu bloggen und die verschiedenen Gründe zu erörtern, warum ich festgestellt habe, dass es besser funktioniert als frühe Rückgaben.

Aber ich schweife ab. Mein Grund, warum ich es hier aufführe, ist, dass ich für Go eine Fehlerbehandlung implementieren müsste, die frühe return s annimmt und die Verwendung break für die Fehlerbehandlung ignoriert

Meine Meinung err == nil ist problematisch

Als weiteren Exkurs möchte ich meine Bedenken bezüglich der idiomatischen Fehlerbehandlung in Go ansprechen. Obwohl ich ein großer Anhänger der Go-Philosophie bin, Fehler zu behandeln, wenn sie auftreten, im Gegensatz zur Ausnahmebehandlung, halte ich die Verwendung von nil , um anzuzeigen, dass kein Fehler vorliegt, für problematisch, da ich häufig feststellen möchte, dass ich eine Erfolgsmeldung zurückgeben möchte eine Routine – zur Verwendung in API-Antworten – und geben nicht nur dann einen Nicht-Null-Wert zurück, wenn ein Fehler auftritt.

Für Go 2 würde ich wirklich gerne sehen, dass Go einen neuen eingebauten Typ status und drei eingebaute Funktionen iserror() , iswarning() , issuccess() hinzufügt. status könnte error implementieren – was viel Abwärtskompatibilität ermöglicht und ein nil -Wert, der an issuccess() übergeben wird, würde true zurückgeben – aber status hätte einen zusätzlichen internen Status für den Fehlerlevel, so dass das Testen des Fehlerlevels immer mit einer der eingebauten Funktionen durchgeführt würde und idealerweise nie mit einem nil -Check. Das würde stattdessen so etwas wie den folgenden Ansatz ermöglichen:

func (me *Config) WriteFile() (sts status) {
    for range only.Once {
        var j []byte
        j, sts = json.MarshalIndent(me, "", "    ")
        if iserror(sts) {
            sts.AddMessage("unable to marshal config")
            break
        }
        sts = me.MaybeMakeDir(me.GetDir(), os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to make directory'%s'", me.GetDir())
            break
        }
        sts = ioutil.WriteFile(string(me.GetFilepath()), j, os.ModePerm)
        if iserror(sts) {
            sts.AddMessage("unable to write to config file '%s'", 
                me.GetFilepath(), 
            )
            break
        }
        sts = fmt.Status("config file written")
    }
    return sts
}

Ich verwende bereits einen Userland-Ansatz in einem Pre-Beta-Level-Paket, das derzeit intern verwendet wird und ähnlich dem oben genannten für die Fehlerbehandlung ist. Ehrlich gesagt verbringe ich viel weniger Zeit damit, darüber nachzudenken, wie Code strukturiert werden soll, wenn ich diesen Ansatz verwende, als wenn ich versuchte, der idiomatischen Go-Fehlerbehandlung zu folgen.

Wenn Sie der Meinung sind, dass es möglich ist, idiomatischen Go-Code für diesen Ansatz weiterzuentwickeln, berücksichtigen Sie dies bitte bei der Implementierung der Fehlerbehandlung, einschließlich bei der Erwägung dieses try() -Vorschlags.

_"Nicht für alle"_ Begründung

Eine der wichtigsten Antworten des Go-Teams war _„Auch dieser Vorschlag versucht nicht, alle Fehlerbehandlungssituationen zu lösen.“_
Und das ist wahrscheinlich die beunruhigendste Sorge aus Governance-Perspektive.

Behandelt diese neue erschwerende Änderung der Sprache, die von jedem verlangen wird, die neuen Konzepte zu lernen, wirklich eine überzeugende Anzahl von Anwendungsfällen?

Und ist das nicht die gleiche Begründung, mit der Mitglieder des Kernteams zahlreiche Feature-Anfragen aus der Community abgelehnt haben? Das Folgende ist ein direktes Zitat aus einem Kommentar eines Mitglieds des Go-Teams in einer archetypischen Antwort auf eine Funktionsanfrage, die vor etwa 2 Jahren eingereicht wurde _(Ich nenne die Person oder die spezifische Funktionsanfrage nicht, da diese Diskussion nicht möglich sein sollte die Menschen, sondern über die Sprache):_

_"Ein neues Sprachfeature braucht überzeugende Anwendungsfälle. Alle Sprachfeatures sind nützlich, sonst würde sie niemand vorschlagen; die Frage ist: Sind sie nützlich genug, um die Komplexität der Sprache zu rechtfertigen und von jedem zu verlangen, die neuen Konzepte zu lernen? Was ist der überzeugende Nutzen Fälle hier? Wie werden die Menschen diese nutzen? Würden die Menschen zum Beispiel erwarten, in der Lage zu sein, ... und wenn ja, wie würden sie das tun? Bringt dieser Vorschlag mehr als nur die Möglichkeit, ...?"_
— Ein Kernmitglied des Go-Teams

Ehrlich gesagt, als ich diese Antworten gesehen habe, habe ich eines von zwei Gefühlen gespürt:

1. Empörung, wenn es ein Merkmal ist, dem ich zustimme, oder
2. Elation, wenn es sich um eine Funktion handelt, mit der ich nicht einverstanden bin.

Aber in jedem Fall waren/sind meine Gefühle irrelevant; Ich verstehe und stimme zu, dass ein Teil des Grundes, warum Go die Sprache ist, in der sich so viele von uns entwickeln, in diesem eifersüchtigen Schutz der Reinheit der Sprache liegt.

Und deshalb beunruhigt mich dieser Vorschlag so, weil das Go-Kernteam diesen Vorschlag auf der gleichen Ebene zu bearbeiten scheint wie jemand, der dogmatisch ein esoterisches Feature will, das die Go-Community auf keinen Fall jemals tolerieren wird.

_(Und ich hoffe wirklich, dass das Team den Boten nicht erschießt und dies als konstruktive Kritik von jemandem auffasst, der sehen möchte, dass Go weiterhin das Beste ist, was es für uns alle sein kann, da ich von ihnen als "Persona non grata" betrachtet werden müsste das Kernteam.)_

Wenn das Erfordernis einer überzeugenden Reihe realer Anwendungsfälle die Messlatte für alle von der Community erstellten Feature-Vorschläge ist, sollte es nicht auch die gleiche Messlatte für _ alle _ Feature-Vorschläge sein?

Verschachtelung von try()

Auch dies wurde von einigen behandelt, aber ich möchte einen Vergleich zwischen try() und der fortgesetzten Forderung nach ternären Operatoren ziehen. Zitat aus den Kommentaren eines anderen Go-Teammitglieds vor etwa 18 Monaten:

_"Beim "Programmieren im großen Stil" (große Codebasen mit großen Teams über lange Zeiträume) wird der Code viel öfter gelesen als geschrieben, also optimieren wir die Lesbarkeit, nicht die Beschreibbarkeit."_

Einer der _hauptsächlichen_ Gründe dafür , ternäre Operatoren nicht hinzuzufügen, ist, dass sie schwer zu lesen und/oder leicht falsch zu lesen sind, wenn sie verschachtelt sind. Das Gleiche kann jedoch auch für verschachtelte try() -Anweisungen wie try(try(try(to()).parse().this)).easily()) gelten.

Weitere Argumente gegen ternäre Operatoren waren, dass sie _„Ausdrücke“_ sind, mit dem Argument, dass verschachtelte Ausdrücke die Komplexität erhöhen können. Aber erzeugt try() nicht auch einen verschachtelbaren Ausdruck?

Nun hat jemand hier gesagt _"Ich denke, Beispiele wie [verschachtelte try() s] sind unrealistisch"_ und diese Aussage wurde nicht in Frage gestellt.

Aber wenn die Leute als Postulat akzeptieren, dass Entwickler try() nicht verschachteln, warum wird dann ternären Operatoren nicht die gleiche Ehrerbietung entgegengebracht, wenn Leute sagen _"Ich denke, tief verschachtelte ternäre Operatoren sind unrealistisch?"_

Fazit für diesen Punkt, ich denke, wenn das Argument gegen ternäre Operatoren wirklich gültig ist, dann sollten sie auch als gültige Argumente gegen diesen try() -Vorschlag betrachtet werden.

Zusammenfassend

Zum Zeitpunkt des Verfassens dieses Artikels stimmen 58% nach unten und 42% nach oben. Ich denke, dies allein sollte ausreichen, um darauf hinzuweisen, dass dieser Vorschlag so spaltend ist, dass es an der Zeit ist, zu diesem Thema zum Reißbrett zurückzukehren.

fwiw

PS Um es augenzwinkernder auszudrücken, ich denke, wir sollten der umschriebenen Weisheit von Yoda folgen:

_"Es gibt kein try() . Nur do() ."_

@ianlancetaylor

@beoran Vielleicht könnten Sie die Verbindung zwischen Generika und Fehlerbehandlung erweitern.

Ich spreche nicht für @beoran , aber in meinem Kommentar von vor ein paar Minuten werden Sie sehen, dass wir unsere eigenen try() bauen könnten, wenn wir Generika _(plus variadische Rückgabeparameter)_ hätten.

Allerdings – und ich werde wiederholen, was ich oben über Generika gesagt habe, hier, wo es einfacher zu sehen sein wird:

_" Ich denke, die Anwendungsfälle für Generika sollten reduziert werden, indem eingebaute Funktionen hinzugefügt werden, um die Anwendungsfälle von Generika zu adressieren, anstatt den verwirrenden Semantik- und Syntaxsalat von Generika von Java et al. hinzuzufügen.)"_

@ianlancetaylor

Bei dem Versuch, eine Antwort auf Ihre Frage zu formulieren, habe ich versucht, die try -Funktion in Go so zu implementieren, wie sie ist, und zu meiner Freude ist es tatsächlich bereits möglich, etwas ganz Ähnliches zu emulieren:

func try(v interface{}, err error) interface{} {
   if err != nil { 
     panic(err)
   }
   return v
}

Sehen Sie hier, wie es verwendet werden kann: https://play.golang.org/p/Kq9Q0hZHlXL

Die Nachteile dieses Ansatzes sind:

1. Eine verzögerte Rettung ist erforderlich, aber mit try wie in diesem Vorschlag ist auch ein verzögerter Handler erforderlich, wenn wir eine ordnungsgemäße Fehlerbehandlung durchführen möchten. Also ich finde das ist kein gravierender Nachteil. Es könnte sogar noch besser sein, wenn Go eine Art von super(arg1, ..., argn) eingebaut hätte, die bewirkt, dass der Aufrufer des Aufrufers, eine Ebene höher in der Aufrufliste, mit den angegebenen Argumenten arg1,...argn zurückkehrt, eine Art Super-Rückgabe wenn du willst.
2. Dieses von mir implementierte try kann nur mit einer Funktion arbeiten, die ein einzelnes Ergebnis und einen Fehler zurückgibt.
3. Sie müssen die zurückgegebenen leeren Schnittstellenergebnisse eingeben.

Generika mit ausreichender Leistung könnten Problem 2 und 3 lösen, sodass nur 1 übrigbleibt, das durch Hinzufügen eines super() gelöst werden könnte. Mit diesen beiden Funktionen könnten wir so etwas bekommen wie:

func (T ... interface{})try(T, err error) super {
   if err != nil { 
      super(err)
   }
  super(T...)
}

Und dann wäre die verzögerte Rettung nicht mehr nötig. Dieser Vorteil wäre auch dann verfügbar, wenn Go keine Generika hinzugefügt werden.

Tatsächlich ist diese Idee eines eingebauten super() so mächtig und interessant, dass ich einen separaten Vorschlag dafür posten könnte.

@beoran Gut zu sehen, dass wir bei der Implementierung try() im Userland unabhängig voneinander auf genau die gleichen Einschränkungen gestoßen sind, mit Ausnahme des Super-Teils, den ich nicht aufgenommen habe, weil ich in einem alternativen Vorschlag über etwas Ähnliches sprechen wollte. :-)

Ich mag den Vorschlag, aber die Tatsache, dass Sie explizit angeben mussten, dass defer try(...) und go try(...) nicht erlaubt sind, ließ mich denken, dass etwas nicht ganz richtig war .... Orthogonalität ist ein guter Designleitfaden. Beim weiteren Lesen und Sehen von Dingen wie
x = try(foo(...)) y = try(bar(...))
Ich frage mich, ob vielleicht try ein Kontext sein muss! Erwägen:
try ( x = foo(...) y = bar(...) )
Hier geben foo() und bar() zwei Werte zurück, von denen der zweite error ist. Try-Semantik spielt nur für Aufrufe innerhalb des try -Blocks eine Rolle, bei denen der zurückgegebene Fehlerwert eliminiert (kein Empfänger) und nicht ignoriert wird (Empfänger ist _ ). Sie können sogar einige Fehler zwischen foo - und bar -Aufrufen behandeln.

Zusammenfassung:
a) Das Problem, try für go und defer nicht zuzulassen, verschwindet aufgrund der Syntax.
b) Fehlerbehandlung mehrerer Funktionen kann ausgeklammert werden.
c) seine magische Natur lässt sich besser als spezielle Syntax als als Funktionsaufruf ausdrücken.

Wenn try ein Kontext ist, dann haben wir gerade try/catch-Blöcke erstellt, die wir ausdrücklich zu vermeiden versuchen (und das aus gutem Grund).

Es gibt keinen Haken. Es würde genau derselbe Code generiert werden wie beim aktuellen Vorschlag
x = try(foo(...)) y = try(bar(...))
Dies ist nur eine andere Syntax, keine Semantik.
````

Ich denke, ich hatte ein paar Annahmen darüber getroffen, die ich nicht hätte tun sollen, obwohl es immer noch ein paar Nachteile gibt.

Was ist, wenn foo oder bar keinen Fehler zurückgeben, können sie auch in den try-Kontext gestellt werden? Wenn nicht, scheint es ziemlich hässlich zu sein, zwischen Fehler- und Nicht-Fehler-Funktionen zu wechseln, und wenn dies möglich ist, greifen wir auf die Probleme von Try-Blöcken in älteren Sprachen zurück.

Die zweite Sache ist, dass die keyword ( ... ) -Syntax normalerweise bedeutet, dass Sie das Schlüsselwort jeder Zeile voranstellen. Also für import, var, const, etc: jede Zeile beginnt mit dem Schlüsselwort. Eine Ausnahme von dieser Regel zu machen, scheint keine gute Entscheidung zu sein

Anstatt eine Funktion zu verwenden, wäre es einfach idiomatischer, eine spezielle Kennung zu verwenden?

Wir haben bereits den leeren Bezeichner _ , der Werte ignoriert.
Wir könnten so etwas wie # haben, das nur in Funktionen verwendet werden kann, deren letzter zurückgegebener Wert vom Typ error ist.

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

Wenn # ein Fehler zugewiesen wird, kehrt die Funktion sofort mit dem empfangenen Fehler zurück. Die Werte der anderen Variablen wären:

• wenn sie nicht als Nullwert bezeichnet werden
• andernfalls der den benannten Variablen zugewiesene Wert

@deanveloper , die Blocksemantik try spielt nur für Funktionen eine Rolle, die einen Fehlerwert zurückgeben und bei denen der Fehlerwert nicht zugewiesen wird. So könnte das letzte Beispiel des vorliegenden Vorschlags auch geschrieben werden als
try(x = foo(...)) try(y = bar(...))
Das Einfügen beider Anweisungen in denselben Block ähnelt dem, was wir für wiederholte import -, const - und var -Anweisungen tun.

Wenn Sie nun z
try( x = foo(...)) go zee(...) defer fum() y = bar(...) )
Das ist gleichbedeutend mit dem Schreiben
try(x = foo(...)) go zee(...) defer fum() try(y = bar(...))
Wenn Sie all dies in einem Versuchsblock ausklammern, wird es weniger beschäftigt.

Erwägen
try(x = foo())
Wenn foo() keinen Fehlerwert zurückgibt, ist dies äquivalent zu
x = foo()

Erwägen
try(f, _ := os.open(filename))
Da der zurückgegebene Fehlerwert ignoriert wird, ist dies gleichbedeutend mit just
f, _ := os.open(filename)

Erwägen
try(f, err := os.open(filename))
Da der zurückgegebene Fehlerwert nicht ignoriert wird, ist dies äquivalent zu
f, err := os.open(filename) if err != nil { return ..., err }
Wie derzeit im Vorschlag angegeben.

Und es entrümpelt auch schön verschachtelte Versuche!

Hier ist ein Link zu dem alternativen Vorschlag, den ich oben erwähnt habe:

• https://github.com/golang/go/issues/32473

Es fordert das Hinzufügen von zwei (2) kleinen, aber universellen Sprachfunktionen, um dieselben Anwendungsfälle wie try() zu adressieren

1. Möglichkeit zum Aufrufen eines func /closure in einer Zuweisungsanweisung.
2. Fähigkeit, break , continue oder return mehr als eine Ebene zu erreichen.

Mit diesen beiden Funktionen wäre es keine _"Magie"_ und ich glaube, ihre Verwendung würde Go-Code erzeugen, der leichter zu verstehen ist und mehr mit dem idiomatischen Go-Code übereinstimmt, mit dem wir alle vertraut sind.

Ich habe den Vorschlag gelesen und mag wirklich, wohin der Versuch geht.

In Anbetracht dessen, wie weit verbreitet try sein wird, frage ich mich, ob es einfacher wäre, es zu einem standardmäßigeren Verhalten zu machen.

Betrachten Sie Karten. Dies gilt:

v := m[key]

wie ist das:

v, ok := m[key]

Was ist, wenn wir Fehler genau so behandeln, wie try es vorschlägt, aber die eingebaute entfernen. Also wenn wir anfangen mit:

v, err := fn()

Anstatt zu schreiben:

v := try(fn())

Wir könnten stattdessen schreiben:

v := fn()

Wenn der err-Wert nicht erfasst wird, wird er genauso behandelt wie try. Es wäre etwas gewöhnungsbedürftig, aber es fühlt sich sehr ähnlich an wie v, ok := m[key] und v, ok := x.(string) . Grundsätzlich führt jeder unbehandelte Fehler dazu, dass die Funktion zurückkehrt und der Fehlerwert gesetzt wird.

Um zu den Schlussfolgerungen und Implementierungsanforderungen der Designdokumente zurückzukehren:

• Die Sprachsyntax wird beibehalten und es werden keine neuen Schlüsselwörter eingeführt
• Es ist weiterhin syntaktischer Zucker wie try und hoffentlich einfach zu erklären.
• Erfordert keine neue Syntax
• Es sollte vollständig abwärtskompatibel sein.

Ich stelle mir vor, dass dies fast die gleichen Implementierungsanforderungen wie try hätte, da der Hauptunterschied eher darin besteht, dass der syntaktische Zucker nicht im eingebauten Zustand ausgelöst wird, jetzt ist es das Fehlen des err-Felds.

Wenn wir also das Beispiel CopyFile aus dem Vorschlag zusammen mit defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) verwenden, erhalten wir:

func CopyFile(src, dst string) (err error) {
        defer fmt.HandleErrorf(&err, "copy %s %s", src, dst)

        r := os.Open(src)
        defer r.Close()

        w := os.Create(dst)
        defer func() {
                err := w.Close()
                if err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        io.Copy(w, r)
        w.Close()
        return nil
}

@savaki Ich mag das und habe darüber nachgedacht, was nötig wäre, um Go dazu zu bringen, die Fehlerbehandlung umzudrehen, indem es standardmäßig immer Fehler behandelt und den Programmierer angeben lässt, wann dies nicht der Fall sein soll (indem er den Fehler in einer Variablen erfasst), aber völlig fehlt Bezeichner würde es schwierig machen, dem Code zu folgen, da man nicht alle Rückkehrpunkte sehen könnte. Möglicherweise könnte eine Konvention zum Benennen von Funktionen, die einen Fehler zurückgeben könnten, anders funktionieren (wie das Großschreiben öffentlicher Bezeichner). Wenn eine Funktion einen Fehler zurückgibt, muss sie immer mit beispielsweise ? enden. Dann könnte Go den Fehler immer implizit behandeln und ihn automatisch an die aufrufende Funktion zurückgeben, genau wie try. Dies macht es sehr ähnlich zu einigen Vorschlägen, die vorschlagen, einen ? Bezeichner anstelle von try zu verwenden, aber ein wichtiger Unterschied besteht darin, dass hier ? Teil des Namens der Funktion und kein zusätzlicher Bezeichner wäre. Tatsächlich würde eine Funktion, die error als letzten Rückgabewert zurückgibt, nicht einmal kompiliert werden, wenn nicht ? angehängt wäre. Natürlich ist ? willkürlich und könnte durch alles andere ersetzt werden, was die Absicht deutlicher macht. operation?() wäre gleichbedeutend mit try(someFunc()) , aber ? wäre Teil des Funktionsnamens und sein einziger Zweck wäre, anzuzeigen, dass die Funktion genau wie die Großschreibung einen Fehler zurückgeben kann der erste Buchstabe einer Variablen.

Dies ist oberflächlich betrachtet sehr ähnlich zu anderen Vorschlägen, die try durch ? ersetzen sollen, aber ein entscheidender Unterschied besteht darin, dass die Fehlerbehandlung implizit (automatisch) und stattdessen das Ignorieren (oder Umbrechen) von Fehlern explizit gemacht wird sowieso eine Art Best Practice. Das offensichtlichste Problem dabei ist natürlich, dass es nicht abwärtskompatibel ist, und ich bin mir sicher, dass es noch viele mehr gibt.

Abgesehen davon wäre ich sehr daran interessiert zu sehen, wie Go die Fehlerbehandlung zum standardmäßigen/impliziten Fall machen kann, indem es sie automatisiert und den Programmierer etwas zusätzlichen Code schreiben lässt, um die Behandlung zu ignorieren/zu überschreiben. Die Herausforderung besteht meines Erachtens darin, alle Rückkehrpunkte in diesem Fall offensichtlich zu machen, da Fehler ohne sie eher zu Ausnahmen werden, in dem Sinne, dass sie von überall her kommen können, da der Ablauf des Programms sie nicht offensichtlich machen würde. Man könnte sagen, dass Fehler implizit mit einem visuellen Indikator gemacht werden, als würde man try implementieren und errcheck zu einem Compiler-Fehler machen.

könnten wir so etwas wie C++-Ausnahmen mit Dekoratoren für alte Funktionen machen?

func some_old_test() (int, error){
    return 0, errors.New("err1")
}
func some_new_test() (int){
        if true {
             return 1
        }
    throw errors.New("err2")
}
func throw_res(int, e error) int {
    if e != nil {
        throw e
    }
    return int
}
func main() {
    fmt.Println("Hello, playground")
    try{
        i := throw_res(some_old_test())
        fmt.Println("i=", i + some_new_test())
    } catch(err io.Error) {
        return err
    } catch(err error) {
        fmt.Println("unknown err", err)
    }
}

@owais Ich dachte, die Semantik wäre genau die gleiche wie try, also müssten Sie zumindest den Fehlertyp deklarieren. Also wenn wir anfangen mit:

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

Wenn ich den Versuchsvorschlag verstehe, mache einfach Folgendes:

func foo() error {
  _  := fn() 
  return nil
} 

würde nicht kompilieren. Ein netter Vorteil ist, dass es der Kompilierung die Möglichkeit gibt, dem Benutzer mitzuteilen, was fehlt. Etwas mit dem Effekt, dass die Verwendung der impliziten Fehlerbehandlung erfordert, dass der Fehlerrückgabetyp benannt wird, err.

Das würde dann funktionieren:

func foo() (err error) {
  _  := fn() 
  return nil
} 

Warum behandeln Sie nicht einfach den Fall eines Fehlers, der keiner Variablen zugewiesen ist?

• Benötigte Rückgaben mit Namen entfernen, der Compiler kann dies alles selbst tun.
• ermöglicht das Hinzufügen von Kontext.
• behandelt den allgemeinen Anwendungsfall.
• abwärtskompatibel
• interagiert nicht seltsam mit Verzögerungen, Schleifen oder Schaltern.

implizite Rückgabe für den Fall if err != nil, Compiler kann lokale Variablennamen für Rückgaben generieren, falls erforderlich, auf die der Programmierer nicht zugreifen kann.
persönlich mag ich diesen speziellen Fall aus Sicht der Code-Lesbarkeit nicht

f := os.Open("foo.txt")

Bevorzugen Sie eine explizite Rückkehr, folgt der Code mehr gelesen als geschrieben Mantra

f := os.Open("foo.txt") else return

interessanterweise könnten wir beide Formen akzeptieren und gofmt automatisch die else-Rückgabe hinzufügen lassen.

Hinzufügen von Kontext, auch lokale Benennung der Variablen. return wird explizit, weil wir Kontext hinzufügen möchten.

f := os.Open("foo.txt") else err {
  return errors.Wrap(err, "some context")
}

Hinzufügen von Kontext mit mehreren Rückgabewerten

f := os.Open("foo.txt") else err {
  return i, j, errors.Wrap(err, "some context")
}

Verschachtelte Funktionen erfordern, dass die äußeren Funktionen alle Ergebnisse in derselben Reihenfolge verarbeiten
abzüglich des letzten Fehlers.

bits := ioutil.ReadAll(os.Open("foo")) else err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

Compiler verweigert die Kompilierung aufgrund eines fehlenden Fehlerrückgabewerts in der Funktion

func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

lässt sich problemlos kompilieren, da Fehler explizit ignoriert werden.

func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
} 

Compiler ist zufrieden. er ignoriert den Fehler wie bisher, da keine Zuweisung oder sonst ein Suffix auftritt.

func foo() error {
  return errors.New("whoops")
}

func bar() {
  foo()
}

Innerhalb einer Schleife können Sie Continue verwenden.

for _, s := range []string{"1","2","3","4","5","6"} {
  i := strconv.Atoi(s) else continue
}

Bearbeiten: ; durch else ersetzt

@savaki Ich glaube, ich habe Ihren ursprünglichen Kommentar verstanden, und ich mag die Idee, dass Go standardmäßig Fehler behandelt, aber ich glaube nicht, dass es ohne das Hinzufügen einiger zusätzlicher Syntaxänderungen möglich ist, und sobald wir das tun, wird es dem aktuellen Vorschlag auffallend ähnlich.

Der größte Nachteil Ihres Vorschlags besteht darin, dass nicht alle Punkte offengelegt werden, von denen eine Funktion zurückkehren kann, im Gegensatz zum aktuellen if err != nil {return err} oder der in diesem Vorschlag eingeführten try-Funktion. Auch wenn es unter der Haube genauso funktionieren würde, würde der Code optisch ganz anders aussehen. Beim Lesen von Code gäbe es keine Möglichkeit zu wissen, welche Funktionsaufrufe einen Fehler zurückgeben könnten. Das wäre meiner Meinung nach eine schlimmere Erfahrung als Ausnahmen.

Möglicherweise könnte die Fehlerbehandlung implizit gemacht werden, wenn der Compiler eine semantische Konvention für Funktionen erzwingt, die Fehler zurückgeben könnten. Als müssten sie mit einem bestimmten Satz oder Zeichen beginnen oder enden. Das würde alle Rückgabepunkte sehr offensichtlich machen, und ich denke, es wäre besser als die manuelle Fehlerbehandlung, aber ich bin mir nicht sicher, wie viel besser es ist, wenn man bedenkt, dass es bereits Flusenprüfungen gibt, die Last schreien, wenn sie einen Fehler entdecken, der ignoriert wird. Es wäre sehr interessant zu sehen, ob der Compiler erzwingen kann, dass Funktionen auf eine bestimmte Weise benannt werden, je nachdem, ob sie mögliche Fehler zurückgeben könnten.

Der Hauptnachteil dieses Ansatzes besteht darin, dass der Fehlerergebnisparameter benannt werden muss, was möglicherweise zu weniger hübschen APIs führt (siehe aber die FAQs zu diesem Thema). Wir glauben, dass wir uns daran gewöhnen werden, wenn sich dieser Stil etabliert hat.

Ich bin mir nicht sicher, ob so etwas schon einmal vorgeschlagen wurde, kann es hier oder im Vorschlag nicht finden. Haben Sie eine andere eingebaute Funktion in Betracht gezogen, die einen Zeiger auf den Fehlerrückgabewert der aktuellen Funktion zurückgibt?
z.B:

func example() error {
        var err *error = funcerror() // always return a non-nil pointer
        fmt.Print(*err) // always nil if the return parameters are not named and not in a defer

        defer func() {
                err := funcerror()
                fmt.Print(*err) // "x"
        }

        return errors.New("x")
}

func exampleNamed() (err error) {
        funcErr := funcerror()
        fmt.Print(*funcErr) // "nil"

        err = errors.New("x")
        fmt.Print(*funcErr) // "x", named return parameter is reflected even before return is called

        *funcErr = errors.New("y")
        fmt.Print(err) // "y", unfortunate side effect?

        defer func() {
                funcErr := funcerror()
                fmt.Print(*funcErr) // "z"
                fmt.Print(err) // "z"
        }

        return errors.New("z")
}

Verwendung mit Versuch:

func CopyFile(src, dst string) (error) {
        defer func() {
                err := funcerror()
                if *err != nil {
                        *err = fmt.Errorf("copy %s %s: %v", src, dst, err)
                }
        }()
        // one liner alternative
        // defer fmt.HandleErrorf(funcerror(), "copy %s %s", src, dst)

        r := try(os.Open(src))
        defer r.Close()

        w := try(os.Create(dst))
        defer func() {
                w.Close()
                err := funcerror()
                if *err != nil {
                        os.Remove(dst) // only if a “try” fails
                }
        }()

        try(io.Copy(w, r))
        try(w.Close())
        return nil
}

Alternativ könnte funcerror (der Name ist in Arbeit :D ) nil zurückgeben, wenn er nicht innerhalb von defer aufgerufen wird.

Eine andere Alternative ist, dass funcerror eine "Errorer"-Schnittstelle zurückgibt, um sie schreibgeschützt zu machen:

type interface Errorer() {
        Error() error
}

@savaki Ich mag deinen Vorschlag, try() wegzulassen und es eher wie das Testen einer Karte oder einer Typenzusicherung zu machen. Das fühlt sich viel mehr _"Go-like"_ an.

Es gibt jedoch immer noch ein eklatantes Problem, das ich sehe, und das ist Ihr Vorschlag, der davon ausgeht, dass alle Fehler, die diesen Ansatz verwenden, ein return auslösen und die Funktion verlassen. Was nicht in Betracht gezogen wird, ist die Ausgabe von break aus den aktuellen for oder continue für die aktuellen for .

Frühe return s sind ein Vorschlaghammer, wenn oft ein Skalpell die bessere Wahl ist.

Ich behaupte also, dass break und continue gültige Strategien zur Fehlerbehandlung sein sollten, und derzeit setzt Ihr Vorschlag nur return $ voraus, während try() dies voraussetzt oder einen Fehler aufruft Handler, der selbst nur return kann, nicht break oder continue .

Sieht aus wie Savaki und ich hatte ähnliche Ideen, ich habe nur die Blocksemantik für den Umgang mit dem Fehler hinzugefügt, falls gewünscht. Zum Beispiel das Hinzufügen von Comtext, für Schleifen, in denen Sie kurzschließen möchten usw

@mikeschinkel siehe meine Erweiterung, er und ich hatten ähnliche Ideen, ich habe sie nur mit einer optionalen Blockanweisung erweitert

@james-lawrence

@mikeckinkel siehe meine Erweiterung, er und ich hatten ähnliche Ideen, ich habe sie nur mit einer optionalen Blockanweisung erweitert

Nimm dein Beispiel:

f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

Im Vergleich zu dem, was wir heute tun:

f,err := os.Open("foo.txt"); 
if err != nil {
  return errors.Wrap(err, "some context")
}

Ist mir definitiv vorzuziehen. Außer es hat ein paar Probleme:

1. err scheint _"magisch"_ deklariert zu sein. Magie sollte minimiert werden, oder? Erklären wir es also:

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

1. Aber das funktioniert immer noch nicht, weil Go weder nil -Werte als false noch Zeigerwerte als true interpretiert, also müsste es so sein:

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

Und was das funktioniert, es fühlt sich nach genauso viel Arbeit und viel Syntax in einer Zeile an, also könnte ich der Übersichtlichkeit halber weiterhin auf die alte Art und Weise vorgehen.

Aber was wäre, wenn Go zwei (2) Builtins hinzufügen würde; iserror() und error() ? Dann könnten wir das tun, was sich für mich nicht so schlimm anfühlt:

f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

Oder besser _(etwas wie):_

f := os.Open("foo.txt"); iserror() {
  return error().Extend("some context")
}

Was denken Sie und andere?

Überprüfen Sie nebenbei die Schreibweise meines Benutzernamens. Ich wäre nicht über Ihre Erwähnung informiert worden, wenn ich nicht sowieso aufgepasst hätte ...

@mikeschinkel Entschuldigung für den Namen, den ich auf meinem Telefon hatte, und Github hat keine Autosuggestion gemacht.

err scheint "magisch" deklariert zu sein. Magie sollte minimiert werden, oder? Erklären wir es also:

meh, die ganze Idee, automatisch eine Rückgabe einzufügen, ist magisch. Das ist kaum das Magischste, was in diesem ganzen Vorschlag vor sich geht. Außerdem würde ich argumentieren, dass der Irrtum erklärt wurde; nur am Ende innerhalb des Kontexts eines bereichsbezogenen Blocks, um zu verhindern, dass er den übergeordneten Bereich verschmutzt, während weiterhin all die guten Dinge beibehalten werden, die wir normalerweise mit if-Anweisungen erhalten.

Ich bin im Allgemeinen ziemlich zufrieden mit der Fehlerbehandlung von go mit den bevorstehenden Ergänzungen des Fehlerpakets. Ich sehe nichts in diesem Vorschlag als super hilfreich. Ich versuche nur, die natürlichste Passform für den Golang anzubieten, wenn wir fest entschlossen sind, dies zu tun.

_"Die ganze Idee des automatischen Einfügens einer Rückgabe ist magisch."_

Da wirst du von mir keine Argumente bekommen.

_"Das ist kaum das Magischste, was in diesem ganzen Vorschlag vor sich geht."_

Ich glaube, ich habe versucht zu argumentieren, dass _"jede Magie problematisch ist."_

_"Außerdem würde ich argumentieren, dass der Fehler deklariert wurde; nur am Ende innerhalb des Kontexts eines Bereichsblocks ..."_

Wenn ich es also err2 nennen wollte, würde das auch funktionieren?

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

Ich gehe also davon aus, dass Sie auch eine Sonderfallbehandlung von err / err2 nach dem Semikolon vorschlagen, dh dass angenommen wird, dass es entweder nil ist oder nicht nil statt bool wie beim Überprüfen einer Karte?

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

Ich bin im Allgemeinen ziemlich zufrieden mit der Fehlerbehandlung von go mit den bevorstehenden Ergänzungen des Fehlerpakets.

Auch ich bin mit der Fehlerbehandlung zufrieden, wenn sie mit break und continue _ kombiniert wird (aber nicht return .)_

So wie es ist, sehe ich diesen try() -Vorschlag eher als schädlich denn als hilfreich an und würde lieber nichts als diese Umsetzung als vorgeschlagen sehen. #jmtcw.

@beoran @mikeschinkel Ich habe vorhin angedeutet, dass wir diese Version von try nicht mit Generika implementieren könnten, weil sie den Kontrollfluss verändert. Wenn ich richtig lese, schlagen Sie beide vor, dass wir Generika verwenden könnten, um try zu implementieren, indem Sie panic aufrufen. Aber diese Version von try macht ausdrücklich nicht panic . Wir können also keine Generika verwenden, um diese Version von try zu implementieren.

Ja, wir könnten Generika verwenden (eine Version von Generika, die erheblich leistungsfähiger ist als die im Designentwurf unter https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md), um eine Funktion zu schreiben die bei Fehlern in Panik gerät. Aber bei Fehlern in Panik zu geraten, ist nicht die Art von Fehlerbehandlung, die Go-Programmierer heute schreiben, und es scheint mir keine gute Idee zu sein.

Die besondere Behandlung von @mikeschinkel wäre, dass der Block nur ausgeführt wird, wenn ein Fehler auftritt.
```
f := os.Open('foo'); err { return err } // err wäre hier immer nicht-nil.

@ianlancetaylor

_"Ja, wir könnten Generika verwenden ... Aber bei Fehlern in Panik zu geraten, ist nicht die Art der Fehlerbehandlung, die Go-Programmierer heute schreiben, und es scheint mir keine gute Idee zu sein."_

Ich stimme Ihnen diesbezüglich tatsächlich stark zu, daher scheint es, dass Sie die Absicht meines Kommentars falsch interpretiert haben. Ich habe keineswegs vorgeschlagen, dass das Go-Team eine Fehlerbehandlung implementiert, die panic() verwendet – natürlich nicht.

Stattdessen habe ich versucht, Ihren Hinweisen aus vielen Ihrer früheren Kommentare zu anderen Themen zu folgen und vorgeschlagen, dass wir keine Änderungen an Go vornehmen, die nicht absolut notwendig sind, da sie stattdessen im Userland möglich sind . Also _wenn_ Generika angesprochen würden _dann_ könnten Leute, die try() wollen, es tatsächlich selbst implementieren, wenn auch unter Nutzung von panic() . Und das wäre eine Funktion weniger, die das Team für Go hinzufügen und dokumentieren müsste.

Was ich nicht tat – und vielleicht war das nicht klar – war, dafür zu plädieren, dass die Leute tatsächlich panic() verwenden, um try() $ zu implementieren, nur dass sie es könnten, wenn sie es wirklich wollten, und sie die Funktionen von hätten Generika.

Klärt das auf?

Für mich ist das Aufrufen panic , wie auch immer das gemacht wird, ganz anders als dieser Vorschlag für try . Obwohl ich denke, dass ich verstehe, was Sie sagen, stimme ich nicht zu, dass sie gleichwertig sind. Selbst wenn wir Generika hätten, die stark genug wären, um eine Version von try zu implementieren, die in Panik gerät, würde meiner Meinung nach immer noch ein vernünftiger Wunsch nach der in diesem Vorschlag vorgestellten Version von try bestehen.

@ianlancetaylor Bestätigt. Auch hier habe ich nach einem Grund gesucht, warum try() nicht hinzugefügt werden muss, anstatt einen Weg zu finden, es hinzuzufügen. Wie ich oben sagte, hätte ich viel lieber nichts Neues für die Fehlerbehandlung als try() , wie hier vorgeschlagen.

Ich persönlich mochte den früheren check -Vorschlag mehr als diesen, basierend auf rein visuellen Aspekten; check hatte die gleiche Kraft wie dieses try() , aber bar(check foo()) ist für mich besser lesbar als bar(try(foo())) (ich brauchte nur eine Sekunde, um die Klammern zu zählen!).

Was noch wichtiger ist, mein größter Kritikpunkt an handle / check war, dass es nicht möglich war, einzelne Schecks auf unterschiedliche Weise zu verpacken – und jetzt hat dieser try() -Vorschlag den gleichen Fehler, beim Aufrufen kniffliger, selten verwendeter, für Neulinge verwirrender Funktionen von Verzögerungen und benannten Rückgaben. Und bei handle hatten wir zumindest die Möglichkeit, Scopes zu verwenden, um Handle-Blöcke zu definieren, bei defer ist selbst das nicht möglich.

Soweit es mich betrifft, verliert dieser Vorschlag in jeder Hinsicht gegenüber dem früheren handle / check Vorschlag.

Hier ist ein weiteres Problem bei der Verwendung von Verzögerungen für die Fehlerbehandlung.

try ist ein kontrolliertes/beabsichtigtes Verlassen einer Funktion. Verzögerungen werden immer ausgeführt, einschließlich unkontrollierter/unbeabsichtigter Beendigungen von Funktionen. Diese Diskrepanz könnte Verwirrung stiften. Hier ist ein imaginäres Szenario:

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

Denken Sie daran, dass sich net/http von einer Panik erholt, und stellen Sie sich vor, Sie müssten ein Produktionsproblem um die Panik herum debuggen. Sie würden sich Ihre Instrumentierung ansehen und einen Anstieg der DB-Aufruffehler aufgrund der recordMetric -Aufrufe feststellen. Dies könnte das wahre Problem verschleiern, nämlich die Panik in der folgenden Zeile.

Ich bin mir nicht sicher, wie ernst dies in der Praxis ist, aber es ist (leider) vielleicht ein weiterer Grund zu der Annahme, dass defer kein idealer Mechanismus für die Fehlerbehandlung ist.

Hier ist eine Änderung, die bei einigen der geäußerten Bedenken hilfreich sein kann: Behandle try wie goto statt wie return . Lass mich ausreden. :)

try wäre stattdessen syntaktischer Zucker für:

t1, … tn, te := f()  // t1, … tn, te are local (invisible) temporaries
if te != nil {
        err = te   // assign te to the error result parameter
        goto error // goto "error" label
}
x1, … xn = t1, … tn  // assignment only if there was no error

Leistungen:

• defer ist nicht erforderlich, um Fehler zu dekorieren. (Named Returns sind jedoch weiterhin erforderlich.)
• Das Vorhandensein des Labels error: ist ein visueller Hinweis darauf, dass sich irgendwo in der Funktion ein try befindet.

Dies bietet auch einen Mechanismus zum Hinzufügen von Handlern, der die Handler-als-Funktion-Probleme umgeht: Verwenden Sie Labels als Handler. try(fn(), wrap) wäre goto wrap statt goto error . Der Compiler kann bestätigen, dass wrap: in der Funktion vorhanden ist. Beachten Sie, dass Handler auch beim Debuggen hilfreich sind: Sie können den Handler hinzufügen/ändern, um einen Debugging-Pfad bereitzustellen.

Beispielcode:

func CopyFile(src, dst string) (err error) {
    r := try(os.Open(src))
    defer r.Close()

    w := try(os.Create(dst))
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “try” fails
        }
    }()

    try(io.Copy(w, r), copyfail)
    try(w.Close())
    return nil

error:
    return fmt.Errorf("copy %s %s: %v", src, dst, err)

copyfail:
    recordMetric("copy failure") // count incidents of this failure
    return fmt.Errorf("copy %s %s: %v", src, dst, err)
}

Andere Kommentare:

• Wir könnten verlangen, dass jedem Label, das als Ziel von try verwendet wird, eine abschließende Anweisung vorangestellt wird. In der Praxis würde dies sie zum Ende der Funktion zwingen und könnte einigen Spaghetti-Code verhindern. Andererseits könnte es einige sinnvolle, hilfreiche Verwendungen verhindern.
• try könnte verwendet werden, um eine Schleife zu erstellen. Ich denke, das fällt unter das Motto "wenn es weh tut, tu es nicht", aber ich bin mir nicht sicher.
• Dazu müsste https://github.com/golang/go/issues/26058 repariert werden.

Kredit: Ich glaube, eine Variante dieser Idee wurde erstmals von @griesemer persönlich auf der GopherCon im letzten Jahr vorgeschlagen.

@josharian Das Nachdenken über die Interaktion mit panic ist hier wichtig, und ich bin froh, dass Sie es angesprochen haben, aber Ihr Beispiel erscheint mir seltsam. Im folgenden Code ergibt es für mich keinen Sinn, dass die Zurückstellung immer eine "db call failed" -Metrik aufzeichnet. Es wäre eine falsche Metrik, wenn someHTTPHandlerGuts erfolgreich ist und nil zurückgibt. Das defer wird in allen Exit-Fällen ausgeführt, nicht nur in Fehler- oder Panikfällen, sodass der Code falsch zu sein scheint, selbst wenn keine Panik vorliegt.

func someHTTPHandlerGuts() (err error) {
  defer func() {
    recordMetric("db call failed")
    return fmt.HandleErrorf("db unavailable: %v", err)
  }()
  data := try(makeDBCall)
  // some code that panics due to a bug
  return nil
}

@josharian Ja, das ist mehr oder weniger genau die Version, die wir letztes Jahr besprochen haben (außer dass wir check statt try verwendet haben). Ich denke, es wäre entscheidend, dass man nicht "zurück" in den Rest des Funktionskörpers springen könnte, sobald wir beim Label error sind. Das würde sicherstellen, dass das goto etwas "strukturiert" ist (kein Spaghetti-Code möglich). Eine Bedenken, die geäußert wurden, war, dass die Fehlerbehandlungsmarke (das error: )-Label immer am Ende der Funktion landen würde (andernfalls müsste man sie irgendwie umgehen). Ich persönlich mag den Code zur Fehlerbehandlung (am Ende), aber andere waren der Meinung, dass er gleich zu Beginn sichtbar sein sollte.

@mikeshenkel Ich sehe die Rückkehr aus einer Schleife eher als Plus denn als Negativ. Ich vermute, dass dies Entwickler ermutigen würde, entweder eine separate Funktion zu verwenden, um den Inhalt einer Schleife zu verarbeiten, oder ausdrücklich err zu verwenden, wie wir es derzeit tun. Beides scheint mir ein gutes Ergebnis zu sein.

Aus meiner Sicht habe ich nicht das Gefühl, dass diese Try-Syntax jeden Anwendungsfall behandeln muss, so wie ich nicht das Gefühl habe, dass ich die verwenden muss

V, ok:= m[Taste]

Formular aus dem Lesen von einer Karte

Sie könnten vermeiden, dass die goto-Labels Handler zum Ende der Funktion zwingen, indem Sie den Vorschlag handle / check in vereinfachter Form wiederbeleben. Was wäre, wenn wir die handle err { ... } -Syntax verwenden, aber keine Handler verketten lassen, sondern nur der letzte verwendet wird. Es vereinfacht diesen Vorschlag sehr und ist der Goto-Idee sehr ähnlich, außer dass es die Handhabung näher an den Verwendungsort bringt.

func CopyFile(src, dst string) (err error) {
    handle err {
        return fmt.Errorf("copy %s %s: %v", src, dst, err)
    }
    r := check os.Open(src)
    defer r.Close()

    w := check os.Create(dst)
    defer func() {
        w.Close()
        if err != nil {
            os.Remove(dst) // only if a “check” fails
        }
    }()

    {
        // handlers are scoped, after this scope the original handle is used again.
        // as an alternative, we could have repeated the first handle after the io.Copy,
        // or come up with a syntax to name the handlers, though that's often not useful.
        handle err {
            recordMetric("copy failure") // count incidents of this failure
            return fmt.Errorf("copy %s %s: %v", src, dst, err)
        }
        check io.Copy(w, r)
    }
    check w.Close()
    return nil
}

Als Bonus hat dies einen zukünftigen Weg, Handler verketten zu lassen, da alle bestehenden Verwendungen eine Rendite haben würden.

@josharian @griesemer Wenn Sie benannte Handler einführen (die viele Antworten zum Überprüfen/Handhaben angefordert haben, siehe wiederkehrende Themen ), gibt es Syntaxoptionen, die try(f(), err) vorzuziehen sind:

try.err f()
try?err f()
try#err f()

?err    f() // because 'try' is redundant
?return f() // no handler
?panic  f() // no handler

(?err f()).method()

f?err() // lead with function name, instead of error handling
f?err().method()

file, ?err := os.Open(...) // many check/handle responses also requested this style

Eines der Dinge, die ich an Go am meisten mag, ist, dass seine Syntax relativ frei von Satzzeichen ist und ohne größere Probleme laut vorgelesen werden kann. Ich würde es wirklich hassen, wenn Go als $#@!perl enden würde.

Für mich hat das "Ausprobieren" einer integrierten Funktion und das Aktivieren von Ketten zwei Probleme:

• Es ist nicht konsistent mit dem Rest des Kontrollflusses in go (z. B. Schlüsselwörter for/if/return/etc).
• Es macht Code weniger lesbar.

Ich würde es vorziehen, es eine Aussage ohne Klammern zu machen. Die Beispiele in dem Vorschlag würden mehrere Zeilen erfordern, würden aber lesbarer werden (dh einzelne "try"-Instanzen wären schwerer zu übersehen). Ja, es würde externe Parser beschädigen, aber ich ziehe es vor, die Konsistenz zu bewahren.

Der ternäre Operator ist ein weiterer Ort, an dem go nichts hat und mehr Tastenanschläge erfordert, aber gleichzeitig die Lesbarkeit / Wartbarkeit verbessert. Das Hinzufügen von "versuchen" in dieser eingeschränkteren Form wird Ausdrucksstärke und Lesbarkeit besser ausbalancieren, IMO.

FWIW, panic beeinflusst den Kontrollfluss und hat Klammern, aber go und defer beeinflussen auch den Fluss und nicht. Ich neige dazu zu denken, dass try defer insofern ähnlicher ist, als es eine ungewöhnliche Flussoperation ist und es gut ist, try (try os.Open(file)).Read(buf) schwieriger zu machen, weil wir Einzeiler entmutigen wollen egal, aber egal. Beides ist in Ordnung.

Vorschlag, den jeder für einen impliziten Namen für eine endgültige Fehlerrückgabevariable hassen wird: $err . Es ist besser als try() IMO. :-)

@griesemer

_"Persönlich mag ich den Code zur Fehlerbehandlung (am Ende)"_

+1 dazu!

Ich finde, dass die Fehlerbehandlung, die _bevor_ der Fehler auftritt, viel schwieriger zu begründen ist als die Fehlerbehandlung, die _nach_ dem Fehler auftritt. Wenn ich mental zurückspringen und mich zwingen muss, dem logischen Fluss zu folgen, fühlt es sich an, als wäre ich zurück im Jahr 1980, als ich Basic mit GOTOs schrieb.

Lassen Sie mich noch einen weiteren möglichen Weg zur Behandlung von Fehlern vorschlagen, wobei ich wieder CopyFile() als Beispiel verwende:

func CopyFile(src, dst string) (err error) {

    r := os.Open(src)
    defer r.Close()

    w := os.Create(dst)
    defer w.Close()

    io.Copy(w, r)
    w.Close()

    for err := error {
        switch err.Source() {
        case w.Close:
            os.Remove(dst) // only if a “try” fails
            fallthrough
        case os.Open, os.Create, io.Copy:
            err = fmt.Errorf("copy %s %s: %v", src, dst, err)
        default:
            err = fmt.Errorf("an unexpected error occurred")
        }
    }

    return err
}

Die erforderlichen Sprachänderungen wären:

1. Ein for error{} -Konstrukt zulassen, ähnlich wie for range{} , aber nur bei einem Fehler eingegeben und nur einmal ausgeführt.

2. Erlauben Sie das Weglassen der Erfassung von Rückgabewerten, die <object>.Error() string implementieren, aber nur, wenn ein for error{} Konstrukt innerhalb desselben func existiert.

3. Bewirken, dass die Programmsteuerung zur ersten Zeile des Konstrukts for error{} springt , wenn ein func einen _"Fehler"_ in seinem letzten Rückgabewert zurückgibt.

4. Bei der Rückgabe eines _"Fehlers"_ würde Go eine Referenz auf die Funktion zuweisen, die den Fehler zurückgegeben hat, der durch <error>.Source() abrufbar sein sollte

Was ist ein _"Fehler"_?

Derzeit wird ein _"Fehler"_ als jedes Objekt definiert, das Error() string implementiert und natürlich nicht nil ist.

Es besteht jedoch häufig die Notwendigkeit, Fehler _sogar bei Erfolg_ zu erweitern, um die Rückgabe von Werten zu ermöglichen, die für Erfolgsergebnisse einer RESTful-API erforderlich sind. Daher würde ich das Go-Team bitten, nicht automatisch davon auszugehen, dass err!=nil _"Fehler"_ bedeutet, sondern stattdessen zu prüfen, ob ein Fehlerobjekt ein IsError() implementiert und ob IsError() true . nil ist, ein _"Fehler"_ ist.

_(Ich spreche nicht unbedingt von Code in der Standardbibliothek, sondern in erster Linie, wenn Sie Ihren Kontrollfluss so wählen, dass er bei einem err!=nil "Fehler"_ verzweigt in Bezug auf Rückgabewerte in unseren Funktionen tun können.)_

Übrigens, jedem zu ermöglichen, auf die gleiche Weise auf einen _"Fehler"_ zu testen, könnte wahrscheinlich am einfachsten durch Hinzufügen einer neuen eingebauten iserror() -Funktion erfolgen :

type ErrorIser interface {
    IsError() bool
}
func iserror(err error) bool {
    if err == nil { 
        return false
    }
    if _,ok := err.(ErrorIser); !ok {
        return true
    }
    return err.IsError()
}

Ein Nebennutzen des Zulassens der Nichterfassung von _"Fehlern"_

Beachten Sie, dass das Nicht-Erfassen des letzten _"Fehlers"_ von func -Aufrufen ein späteres Refactoring ermöglichen würde, um Fehler von func s zurückzugeben, die ursprünglich keine Fehler zurückgeben mussten. Und es würde dieses Refactoring ermöglichen , ohne bestehenden Code zu beschädigen , der diese Form der Fehlerbehebung verwendet und die besagten func s aufruft.

Für mich ist diese Entscheidung _"Soll ich einen Fehler zurückgeben oder auf die Fehlerbehandlung verzichten, um den Aufruf zu vereinfachen?"_ eines meiner größten Dilemmas beim Schreiben von Go-Code. Das Nicht-Erfassen von _"Fehlern"_ oben zuzulassen, würde dieses Dilemma so gut wie beseitigen.

Eigentlich habe ich vor etwa einem halben Jahr versucht, diese Idee als Go-Übersetzer umzusetzen. Ich bin mir nicht sicher, ob diese Funktion als integriertes Go hinzugefügt werden sollte, aber lassen Sie mich Ihre Erfahrung teilen (obwohl ich nicht sicher bin, ob sie nützlich ist).

https://github.com/rhysd/trygo

Ich habe die erweiterte Sprache TryGo genannt und den TryGo to Go-Übersetzer implementiert.

Mit dem Übersetzer, dem Code

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd := try(os.Getwd())

    try(os.Mkdir(filepath.Join(cwd, subdir)))

    p := filepath.Join(cwd, subdir, filename)
    f := try(os.Create(p))
    defer f.Close()

    try(f.Write(content))

    fmt.Println("Created:", p)
    return nil
}

übersetzen kann

func CreateFileInSubdir(subdir, filename string, content []byte) error {
    cwd, _err0 := os.Getwd()
    if _err0 != nil {
        return _err0
    }

    if _err1 := os.Mkdir(filepath.Join(cwd, subdir)); _err1 != nil {
        return _err1
    }

    p := filepath.Join(cwd, subdir, filename)
    f, _err2 := os.Create(p)
    if _err2 != nil {
        return _err2
    }
    defer f.Close()

    if _, _err3 := f.Write(content); _err3 != nil {
        return _err3
    }

    fmt.Println("Created:", p)
    return nil
}

Für die Einschränkung der Sprache konnte ich den generischen try() -Aufruf nicht implementieren. Es ist beschränkt auf

• RHS der Definitionserklärung
• RHS der Abtretungserklärung
• Anruferklärung

aber ich könnte das mit meinem kleinen Projekt versuchen. Meine Erfahrung war

• es funktioniert im Grunde gut und spart mehrere Zeilen
• Der benannte Rückgabewert ist für err eigentlich unbrauchbar, da der Rückgabewert seiner Funktion sowohl von der Zuweisung als auch von der Sonderfunktion try() bestimmt wird. sehr verwirrend
• dieser try() -Funktion fehlte die oben beschriebene Funktion „Umbruchfehler“.

_"Beides scheint mir ein gutes Ergebnis zu sein."_

Hier müssen wir uns einigen, nicht zuzustimmen.

_"diese Try-Syntax (muss nicht) jeden Anwendungsfall abdecken"_

Dieses Meme ist wahrscheinlich das beunruhigendste. Zumindest wenn man bedenkt, wie widerstandsfähig das Go-Team / die Go-Community gegenüber Änderungen in der Vergangenheit war, die nicht allgemein anwendbar sind.

Wenn wir diese Rechtfertigung hier zulassen, warum können wir dann nicht auf frühere Vorschläge zurückgreifen, die abgelehnt wurden, weil sie nicht allgemein anwendbar waren?

Und sind wir jetzt bereit, für Änderungen in Go zu argumentieren, die nur für ausgewählte Grenzfälle nützlich sind?

Meiner Meinung nach wird es langfristig keine guten Ergebnisse bringen, diesen Präzedenzfall zu schaffen ...

_"@mikeschenkel"_

PS Ich habe Ihre Nachricht wegen eines Rechtschreibfehlers zuerst nicht gesehen. _(das beleidigt mich nicht, ich werde nur nicht benachrichtigt, wenn mein Benutzername falsch geschrieben ist...)_

Ich schätze die Verpflichtung zur Abwärtskompatibilität, die Sie dazu motiviert, try zu einem eingebauten und nicht zu einem Schlüsselwort zu machen, aber nachdem Sie mit der völligen _Seltsamkeit_ gerungen haben, eine häufig verwendete Funktion zu haben, die den Kontrollfluss ändern kann ( panic und recover extrem selten sind), frage ich mich: Hat jemand eine groß angelegte Analyse der Häufigkeit von try als Kennung in Open-Source-Codebasen durchgeführt? Ich war neugierig und skeptisch, also habe ich eine vorläufige Suche nach Folgendem durchgeführt:

• https://github.com/google/go-github
• https://github.com/cockroachdb/cockroach
• https://github.com/golang/net
• https://github.com/exercism/xgo
• https://github.com/GoogleCloudPlatform/kubernetes
• https://github.com/syncthing/syncthing
• https://github.com/mitchellh/packer
• https://github.com/drone/drone
• https://github.com/coreos/etcd
• https://github.com/docker/docker
• https://github.com/sjwhitworth/golearn
• https://github.com/bitly/nsq
• https://github.com/smartystreets/goconvey
• https://github.com/golang/tools
• https://github.com/coreos/fleet
• https://github.com/limetext/lime
• https://github.com/flynn/flynn
• https://github.com/dropbox/godropbox
• https://github.com/hashicorp/consul
• https://github.com/hashicorp/terraform

In den 11.108.770 signifikanten Go-Linien, die in diesen Depots leben, gab es nur 63 Instanzen von try , die als Kennung verwendet wurden. Natürlich ist mir klar, dass diese Codebasen (obwohl sie groß, weit verbreitet und an sich wichtig sind) nur einen Bruchteil des Go-Codes da draußen darstellen, und dass wir außerdem keine Möglichkeit haben, private Codebasen direkt zu analysieren, aber es ist sicher ein interessantes Ergebnis.

Da try außerdem wie jedes Schlüsselwort in Kleinbuchstaben geschrieben ist, werden Sie es niemals in der öffentlichen API eines Pakets finden. Schlüsselwortergänzungen wirken sich nur auf Paketinterna aus.

Dies ist alles ein Vorwort zu ein paar Ideen, die ich in die Mischung einbringen wollte, die von try als Schlüsselwort profitieren würden.

Ich würde folgende Konstruktionen vorschlagen.

1) Kein Handler

// The existing proposal, but as a keyword rather than builtin.  When an error is 
// "caught", the function returns all zero values plus the error.  Nothing 
// particularly new here.
func doSomething() (int, error) {
    try SomeFunc()
    a, b := try AnotherFunc()

    // ...

    return 123, nil
}

2) Handler

Beachten Sie, dass Fehlerbehandlungsroutinen einfache Codeblöcke sind, die eingebettet werden sollen, und keine Funktionen. Mehr dazu weiter unten.

func doSomething() (int, error) {
    // Inline error handler
    a, b := try SomeFunc() else err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    // Named error handlers
    handler logAndContinue err {
        log.Errorf("non-critical error: %v", err)
    }
    handler annotateAndReturn err {
        return 0, errors.Wrap(err, "error in doSomething:")
    }

    c, d := try SomeFunc() else logAndContinue
    e, f := try OtherFunc() else annotateAndReturn

    // ...

    return 123, nil
}

Vorgeschlagene Beschränkungen:

• Sie können nur try eine Funktion aufrufen. Nein try err .
• Wenn Sie keinen Handler angeben, können Sie innerhalb einer Funktion, die einen Fehler als Rückgabewert ganz rechts zurückgibt, nur try ausgeben. Das Verhalten try ändert sich je nach Kontext nicht. Es gerät nie in Panik (wie viel früher im Thread besprochen).
• Es gibt keinerlei "Handler-Kette". Handler sind nur inlineable Codeblöcke.

Leistungen:

• Die Syntax try / else könnte trivial in das bestehende „compound if“ desugered werden:
  go a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "error in doSomething:") }
  wird
  go if a, b, err := SomeFunc(); err != nil { return 0, errors.Wrap(err, "error in doSomething:") }
  In meinen Augen erschienen zusammengesetzte ifs aus einem sehr einfachen Grund immer eher verwirrend als hilfreich: Bedingungen treten im Allgemeinen _nach_ einer Operation auf und haben etwas mit der Verarbeitung ihrer Ergebnisse zu tun. Wenn die Operation in die bedingte Anweisung eingeklemmt ist, ist es einfach weniger offensichtlich, dass sie stattfindet. Das Auge wird abgelenkt. Außerdem ist der Geltungsbereich der definierten Variablen nicht so offensichtlich, als wenn sie ganz links in einer Zeile stehen.
• Error-Handler sind absichtlich nicht als Funktionen definiert (noch mit irgendetwas, das einer funktionsähnlichen Semantik ähnelt). Dies bewirkt mehrere Dinge für uns:
  
  
  
  • Der Compiler kann einen benannten Handler einfach überall dort einfügen, wo auf ihn verwiesen wird. Es ist viel mehr wie ein einfaches Makro/Codegen-Template als ein Funktionsaufruf. Die Laufzeit muss nicht einmal wissen, dass Handler existieren.
  
  
  • Wir sind nicht darauf beschränkt, was wir innerhalb eines Handlers tun können. Wir umgehen die Kritik von check / handle , dass „dieses Fehlerbehandlungs-Framework nur für Rettungsaktionen gut ist“. Wir umgehen auch die Kritik an der "Händlerkette". Jeder beliebige Code kann in einen dieser Handler eingefügt werden, und es wird kein anderer Kontrollfluss impliziert.
  
  
  • Wir müssen return im Handler nicht kapern, um super return zu bedeuten. Das Entführen eines Schlüsselworts ist äußerst verwirrend. return bedeutet einfach nur return , und es besteht keine wirkliche Notwendigkeit für super return .
  
  
  • defer muss nicht als Fehlerbehandlungsmechanismus dienen. Wir können es weiterhin hauptsächlich als eine Möglichkeit betrachten, Ressourcen zu bereinigen usw.
  
  
• Zum Hinzufügen von Kontext zu Fehlern:
  
  
  
  • Das Hinzufügen von Kontext mit Handlern ist extrem einfach und sieht bestehenden if err != nil -Blöcken sehr ähnlich
  
  
  • Auch wenn das Konstrukt „try without handler“ nicht direkt dazu auffordert, Kontext hinzuzufügen, ist es sehr einfach, es in das Handler-Formular umzugestalten. Seine beabsichtigte Verwendung wäre hauptsächlich während der Entwicklung, und es wäre äußerst einfach, einen go vet -Check zu schreiben, um nicht behandelte Fehler hervorzuheben.
  
  

Entschuldigen Sie, wenn diese Ideen anderen Vorschlägen sehr ähnlich sind – ich habe versucht, mit ihnen allen Schritt zu halten, aber möglicherweise einen guten Deal verpasst.

@brynbellomy Danke für die Keyword-Analyse – das sind sehr hilfreiche Informationen. Es scheint, dass try als Schlüsselwort in Ordnung sein könnte. (Sie sagen, dass APIs nicht betroffen sind – das stimmt, aber try wird möglicherweise immer noch als Parametername oder ähnliches angezeigt – daher muss die Dokumentation möglicherweise geändert werden. Aber ich stimme zu, dass dies keine Auswirkungen auf Clients dieser Pakete hätte.)

Zu Ihrem Vorschlag: Es würde auch ohne benannte Handler gut gehen, oder? (Das würde den Vorschlag ohne Leistungsverlust vereinfachen. Man könnte einfach eine lokale Funktion aus dem eingebetteten Handler aufrufen.)

Zu Ihrem Vorschlag: Es würde auch ohne benannte Handler gut gehen, oder? (Das würde den Vorschlag ohne Leistungsverlust vereinfachen. Man könnte einfach eine lokale Funktion aus dem eingebetteten Handler aufrufen.)

@griesemer In der Tat – ich fühlte mich ziemlich lauwarm, diese einzubeziehen. Sicherlich mehr Go-ish ohne.

Auf der anderen Seite scheinen die Leute die Möglichkeit zu haben, eine Einzeiler-Fehlerbehandlung durchzuführen, einschließlich Einzeiler, die return . Ein typischer Fall wäre log, dann return . Wenn wir in der else -Klausel eine lokale Funktion berappen, verlieren wir das wahrscheinlich:

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

(Ich bevorzuge dies jedoch immer noch gegenüber zusammengesetzten ifs)

Sie könnten jedoch immer noch einzeilige Rückgaben erhalten, die einen Fehlerkontext hinzufügen, indem Sie eine einfache gofmt -Optimierung implementieren, die weiter oben im Thread besprochen wurde:

a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

Ist das neue Schlüsselwort im obigen Vorschlag erforderlich? Warum nicht:

SomeFunc() else return
a, b := SomeOtherFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

@griesemer Wenn Handler wieder auf dem Tisch sind, schlage ich vor, dass Sie ein neues Thema zur Diskussion von try/handle oder try/_label_ erstellen. Dieser Vorschlag verzichtet ausdrücklich auf Handler, und es gibt unzählige Möglichkeiten, sie zu definieren und aufzurufen.

Jeder, der Handler vorschlägt, sollte zuerst das Check/Handle-Feedback-Wiki lesen. Die Chancen stehen gut, dass alles, was Sie sich erträumen, dort bereits beschrieben ist :-)
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

@smonkewitz nein, ein neues Schlüsselwort ist in dieser Version nicht erforderlich, da es an Zuweisungsanweisungen gebunden ist, die bisher in verschiedenen Syntaxzuckern mehrfach erwähnt wurden.

https://github.com/golang/go/issues/32437#issuecomment -499808741
https://github.com/golang/go/issues/32437#issuecomment -499852124
https://github.com/golang/go/issues/32437#issuecomment -500095505

@ianlancetaylor hat das Go-Team diese besondere Art der Fehlerbehandlung schon in Betracht gezogen? Es ist nicht so einfach zu implementieren wie der vorgeschlagene eingebaute Versuch, fühlt sich aber idiomatischer an. ~unnötige Aussage, sorry.~

Ich möchte etwas wiederholen, was @deanveloper und einige andere gesagt haben, aber mit meiner eigenen Betonung. In https://github.com/golang/go/issues/32437#issuecomment -498939499 sagte @deanveloper:

try ist eine bedingte Rückgabe. Sowohl Kontrollfluss als auch Rückgaben werden in Go auf Sockeln gehalten. Der gesamte Kontrollfluss innerhalb einer Funktion ist eingerückt und alle Rückgaben beginnen mit return . Das Mischen dieser beiden Konzepte zu einem leicht zu übersehenden Funktionsaufruf fühlt sich einfach ein bisschen daneben an.

Darüber hinaus ist try in diesem Vorschlag eine Funktion, die Werte zurückgibt, sodass sie als Teil eines größeren Ausdrucks verwendet werden kann.

Einige haben argumentiert, dass panic bereits den Präzedenzfall für eine eingebaute Funktion geschaffen hat, die den Kontrollfluss ändert, aber ich denke, dass panic aus zwei Gründen grundlegend anders ist:

1. Panik ist nicht bedingt; es bricht immer die aufrufende Funktion ab.
2. Panic gibt keine Werte zurück und kann daher nur als eigenständige Anweisung erscheinen, was seine Sichtbarkeit erhöht.

Versuchen Sie es dagegen:

1. Bedingt ist; es kann von der aufrufenden Funktion zurückkehren oder nicht.
2. Gibt Werte zurück und kann in einem zusammengesetzten Ausdruck erscheinen, möglicherweise mehrmals, in einer einzelnen Zeile, möglicherweise über den rechten Rand meines Editorfensters hinaus.

Aus diesen Gründen denke ich, dass sich try mehr als nur ein bisschen anfühlt, ich denke, es schadet der Lesbarkeit des Codes grundlegend.

Wenn wir heute zum ersten Mal auf einen Go-Code stoßen, können wir ihn schnell überfliegen, um die möglichen Austrittspunkte und Kontrollflusspunkte zu finden. Ich glaube, das ist eine sehr wertvolle Eigenschaft des Go-Codes. Mit try wird es zu einfach, Code zu schreiben, dem diese Eigenschaft fehlt.

Ich gebe zu, dass es wahrscheinlich ist, dass Go-Entwickler, die Wert auf Lesbarkeit des Codes legen, sich auf Verwendungsausdrücke für try konvergieren würden, die diese Fallstricke bei der Lesbarkeit vermeiden. Ich hoffe, dass dies passieren würde, da die Lesbarkeit des Codes für viele Go-Entwickler ein zentraler Wert zu sein scheint. Aber es ist für mich nicht offensichtlich, dass try bestehenden Code-Idiomen genügend Wert hinzufügt, um das Gewicht zu tragen, der Sprache ein neues Konzept hinzuzufügen, das jeder lernen kann, und das kann so leicht die Lesbarkeit beeinträchtigen.

````
wenn es != "pleite" {
nicht reparieren
}

@ChrisHines Zu Ihrem Punkt (der an anderer Stelle in diesem Thread wiederholt wird) fügen wir eine weitere Einschränkung hinzu:

• jede try -Anweisung (auch solche ohne Handler) muss in einer eigenen Zeile stehen.

Sie würden immer noch von einer großen Reduzierung des visuellen Rauschens profitieren. Dann haben Sie garantierte Rückgaben, die mit return kommentiert sind, und bedingte Rückgaben, die mit try kommentiert sind, und diese Schlüsselwörter stehen immer am Anfang einer Zeile (oder im schlimmsten Fall direkt nach einer Variablenzuweisung).

Also nichts von diesem Unsinn:

try EmitEvent(try (try DecodeMsg(m)).SaveToDB())

sondern das:

dm := try DecodeMsg(m)
um := try dm.SaveToDB()
try EmitEvent(um)

was sich immer noch klarer anfühlt als das:

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

Eine Sache, die ich an diesem Design mag, ist, dass es unmöglich ist, Fehler stillschweigend zu ignorieren, ohne dennoch zu kommentieren, dass einer auftreten könnte . Während Sie jetzt manchmal x, _ := SomeFunc() sehen (was ist der ignorierte Rückgabewert? ein Fehler? etwas anderes?), müssen Sie jetzt klar kommentieren:

x := try SomeFunc() else err {}

Seit meinem vorherigen Beitrag zur Unterstützung des Vorschlags habe ich zwei Ideen gesehen, die von @jagv (parameterlose try gibt *error zurück) und von @josharian (gekennzeichnet als Fehlerbehandler) gepostet wurden, an die ich glaube leicht modifizierte Form würde den Vorschlag erheblich aufwerten.

Wenn ich diese Ideen mit einer weiteren kombiniere, die ich selbst hatte, hätten wir vier Versionen von try :

1. Versuchen()
2. versuchen (Parameter)
3. try(params, label)
4. Versuch (Parameter, Panik)

1 würde einfach einen Zeiger auf den Fehlerrückgabeparameter (ERP) zurückgeben oder nil, wenn es keinen gibt (nur #4). Dies würde eine Alternative zu einem benannten ERP darstellen, ohne dass eine weitere Integration hinzugefügt werden müsste.

2 würde genau so funktionieren, wie es derzeit vorgesehen ist. Ein Nicht-Null-Fehler würde sofort zurückgegeben, könnte aber durch eine defer -Anweisung ergänzt werden.

3 würde wie von @josharian vorgeschlagen funktionieren, dh bei einem Nicht-Null-Fehler würde der Code zum Label verzweigen. Es gäbe jedoch kein Standard-Error-Handler-Label, da dieser Fall nun zu #2 degenerieren würde.

Es scheint mir, dass dies normalerweise eine bessere Möglichkeit ist, Fehler zu dekorieren (oder sie lokal zu behandeln und dann nil zurückzugeben) als defer , da es einfacher und schneller ist. Wem es nicht gefiel, konnte immer noch #2 verwenden.

Es wäre eine bewährte Methode, das Label/den Code zur Fehlerbehandlung am Ende der Funktion zu platzieren und nicht in den Rest des Funktionskörpers zurückzuspringen. Ich denke jedoch nicht, dass der Compiler sie erzwingen sollte, da es gelegentliche Gelegenheiten geben kann, in denen sie nützlich sind, und die Erzwingung in jedem Fall schwierig sein könnte.

Also würde normales Label- und goto -Verhalten gelten, sofern (wie @josharian sagte) #26058 zuerst behoben wird, aber ich denke, es sollte trotzdem behoben werden.

Der Name des Labels darf nicht panic lauten, da dies zu Konflikten mit #4 führen würde.

4 würde panic sofort zurückgeben oder verzweigen. Wenn dies die einzige Version von try wäre, die in einer bestimmten Funktion verwendet wird, wäre folglich kein ERP erforderlich.

Ich habe dies hinzugefügt, damit das Testpaket so funktionieren kann, wie es jetzt funktioniert, ohne dass weitere eingebaute oder andere Änderungen erforderlich sind. Es könnte jedoch auch in anderen _fatalen_ Szenarien nützlich sein.

Dies muss eine separate Version von try sein, da die Alternative zum Verzweigen zu einem Fehlerbehandler und dann in Panik geraten immer noch ein ERP erfordern würde.

Eine der stärksten Reaktionen auf den ursprünglichen Vorschlag war die Besorgnis, dass der normale Fluss, in den eine Funktion zurückkehrt, nicht mehr leicht sichtbar ist.

Zum Beispiel drückte @deanveloper diese Besorgnis sehr gut in https://github.com/golang/go/issues/32437#issuecomment -498932961 aus, was meiner Meinung nach der am höchsten bewertete Kommentar hier ist.

@dominikh schrieb in https://github.com/golang/go/issues/32437#issuecomment -499067357:

In gofmt-codiertem Code stimmt ein return immer mit /^\t*return / überein – es ist ein sehr triviales Muster, das ohne Hilfe mit dem Auge zu erkennen ist. try hingegen kann überall im Code vorkommen, beliebig tief in Funktionsaufrufen verschachtelt. Selbst noch so viel Training wird uns nicht in die Lage versetzen, den gesamten Kontrollfluss in einer Funktion ohne Werkzeugunterstützung sofort zu erkennen.

Um dabei zu helfen, schlug @brynbellomy gestern vor:

Jede try-Anweisung (auch solche ohne Handler) muss in einer eigenen Zeile stehen.

Weiterführend könnte das try der Anfang der Zeile sein, sogar für eine Zuweisung.

Es könnte also sein:

try dm := DecodeMsg(m)
try um := dm.SaveToDB()
try EmitEvent(um)

anstelle des Folgenden (aus dem Beispiel von @brynbellomy ):

dm, err := DecodeMsg(m)
if err != nil {
    return nil, err
}

um, err := dm.SaveToDB()
if err != nil {
    return nil, err
}

err = EmitEvent(um)
if err != nil {
    return nil, err
}

Das scheint, es würde auch ohne Editor- oder IDE-Unterstützung ein gutes Maß an Sichtbarkeit bewahren und gleichzeitig die Boilerplate reduzieren.

Das könnte mit dem derzeit vorgeschlagenen verzögerungsbasierten Ansatz funktionieren, der auf benannten Ergebnisparametern beruht, oder es könnte mit der Angabe normaler Handlerfunktionen funktionieren. (Das Angeben von Handler-Funktionen, ohne dass benannte Rückgabewerte erforderlich sind, scheint mir besser zu sein, als dass benannte Rückgabewerte erforderlich sind, aber das ist ein separater Punkt).

Der Vorschlag enthält dieses Beispiel:

info := try(try(os.Open(file)).Stat())    // proposed try built-in

Das könnte stattdessen sein:

try f := os.Open(file)
try info := f.Stat()

Das ist immer noch eine Reduzierung der Textbausteine ​​im Vergleich zu dem, was jemand heute schreiben könnte, wenn auch nicht ganz so kurz wie die vorgeschlagene Syntax. Vielleicht wäre das kurz genug?

@elagergren-spideroak lieferte dieses Beispiel:

try(try(try(to()).parse().this)).easily())

Ich denke, das hat nicht übereinstimmende Klammern, was vielleicht ein absichtlicher Punkt oder ein subtiler Humor ist, also bin ich mir nicht sicher, ob dieses Beispiel beabsichtigt, 2 try oder 3 try zu haben. In jedem Fall wäre es vielleicht besser, dies auf 2-3 Zeilen zu verteilen, die mit try beginnen.

@thepudds , darauf wollte ich in meinem früheren Kommentar hinaus. Außer dem gegebenen

try f := os.Open(file)
try info := f.Stat()

Es liegt auf der Hand, sich try als Try-Block vorzustellen, in dem mehr als ein Satz in Klammern gesetzt werden kann. So kann das obige werden

try (
    f := os.Open(file)
    into := f.Stat()
)

Wenn der Compiler damit umzugehen weiß, funktioniert das Gleiche auch beim Verschachteln. So jetzt kann das obige werden

try info := os.Open(file).Stat()

Aus Funktionssignaturen weiß der Compiler, dass Open einen Fehlerwert zurückgeben kann, und da es sich in einem try-Block befindet, muss es eine Fehlerbehandlung generieren und dann Stat() für den primär zurückgegebenen Wert aufrufen und so weiter.

Als Nächstes lassen Sie Anweisungen zu, bei denen entweder kein Fehlerwert generiert oder lokal behandelt wird. So kann man jetzt sagen

try (
    f := os.Open(file)
    debug("f: %v\n", f) // debug returns nothing
    into := f.Stat()
)

Dies ermöglicht die Entwicklung von Code, ohne Try-Blöcke neu anordnen zu müssen. Aber aus irgendeinem seltsamen Grund scheinen die Leute zu denken, dass die Fehlerbehandlung explizit angegeben werden muss! Sie wollen

try(try(try(to()).parse()).this)).easily())

Während es mir vollkommen gut geht

try to().parse().this().easily()

Obwohl in beiden Fällen genau derselbe Fehlerprüfcode generiert werden kann. Meiner Ansicht nach können Sie bei Bedarf immer speziellen Code für die Fehlerbehandlung schreiben. try (oder wie auch immer Sie es nennen möchten) entrümpelt einfach die standardmäßige Fehlerbehandlung (die darin besteht, sie dem Aufrufer zu zeigen).

Ein weiterer Vorteil besteht darin, dass der Compiler, wenn er die Standardfehlerbehandlung generiert, weitere identifizierende Informationen hinzufügen kann, damit Sie wissen, welche der vier oben genannten Funktionen fehlgeschlagen sind.

Ich war etwas besorgt über die Lesbarkeit von Programmen, in denen try in anderen Ausdrücken vorkommt. Also habe ich grep "return .*err$" in der Standardbibliothek ausgeführt und angefangen, Blöcke nach dem Zufallsprinzip zu lesen. Es gibt 7214 Ergebnisse, ich habe nur ein paar hundert gelesen.

Das erste, was zu beachten ist, ist, dass dort, wo try zutrifft, fast alle diese Blöcke ein wenig besser lesbar werden.

Die zweite Sache ist, dass nur sehr wenige davon, weniger als 1 von 10, try in einen anderen Ausdruck einfügen würden. Der typische Fall sind Anweisungen der Form x := try(...) oder ^try(...)$ .

Hier sind einige Beispiele, bei denen try in einem anderen Ausdruck erscheinen würde:

Text/Vorlage

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

wird:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        return !try(le(arg1, arg2)), nil
}

Text/Vorlage

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

wird

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                if x := v.MapIndex(try(prepareArg(index, v.Type().Key()))); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

(Dies ist das fragwürdigste Beispiel, das ich gesehen habe)

regulärer Ausdruck/Syntax:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

wird

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        c, t = try(nextRune(t))
        p.literal(c)
        ...
}

Dies ist kein Beispiel für try in einem anderen Ausdruck, aber ich möchte es hervorheben, weil es die Lesbarkeit verbessert. Hier ist viel einfacher zu sehen, dass die Werte von c und t außerhalb des Geltungsbereichs der if-Anweisung leben.

net/http

net/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

wird:

        req.Header = Header(try(tp.ReadMIMEHeader())

Datenbank/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

wird

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

Datenbank/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

wird

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }

net/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

wird

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                return try(p.t.dialclientconn(addr, singleuse))
        }

net/http

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

wird

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

(Diese hier gefällt mir sehr gut.)

net/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

wird

        hc = try(fr.ReadFrame()).(*http2ContinuationFrame)// guaranteed by checkFrameOrder

}

(Auch schön.)

Netto :

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

wird

        if ctrlFn != nil {
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), try(newRawConn(fd))))
        }

vielleicht ist das zu viel, und stattdessen sollte es sein:

        if ctrlFn != nil {
                c := try(newRawConn(fd))
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), c))
        }

Insgesamt genieße ich die Wirkung von try auf den Code der Standardbibliothek, den ich durchgelesen habe.

Ein letzter Punkt: Zu sehen, dass try über die wenigen Beispiele im Vorschlag hinaus zum Lesen von Code angewendet wurden, war aufschlussreich. Ich denke, es ist eine Überlegung wert, ein Tool zu schreiben, um Code automatisch zu konvertieren, um try zu verwenden (wo es die Semantik des Programms nicht ändert). Es wäre interessant, ein Beispiel der Diffs zu lesen, das gegen beliebte Pakete auf Github produziert wird, um zu sehen, ob das, was ich in der Standardbibliothek gefunden habe, Bestand hat. Die Ergebnisse eines solchen Programms könnten zusätzliche Einblicke in die Wirkung des Vorschlags geben.

@crawshaw danke dafür, es war toll, es in Aktion zu sehen. Aber als ich es in Aktion sah, nahm ich die Argumente gegen die Inline-Fehlerbehandlung, die ich bisher zurückgewiesen hatte, ernster.

Da dies in so unmittelbarer Nähe zu @thepudds interessantem Vorschlag war, try zu einer Aussage zu machen, habe ich alle Beispiele mit dieser Syntax neu geschrieben und fand sie viel klarer als entweder den Ausdruck - try oder den Status quo, ohne dass zu viele zusätzliche Zeilen erforderlich sind:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

Dieser wäre wohl besser mit einem Ausdruck - try , wenn es mehrere Felder gäbe, die try -ed werden müssten, aber ich bevorzuge immer noch das Gleichgewicht dieses Kompromisses

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

Dies ist im Grunde der schlimmste Fall und sieht gut aus:

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

Ich habe mit mir selbst darüber diskutiert, ob if try legal sein würde oder sollte, aber ich konnte keine vernünftige Erklärung finden, warum es nicht sein sollte, und es funktioniert hier ganz gut:

func (f *http2Framer) endWrite() error {
        ...
        if try n := f.w.Write(f.wbuf); n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

Wenn ich mir die Beispiele von @crawshaw ansehe , fühle ich mich nur noch sicherer, dass der Kontrollfluss oft kryptisch genug gemacht wird, um noch vorsichtiger mit dem Design umzugehen. Selbst eine kleine Menge an Komplexität zu erzählen, wird schwierig zu lesen und leicht zu verpfuschen. Ich bin froh, dass Optionen in Betracht gezogen werden, aber die Verkomplizierung des Kontrollflusses in einer so zurückhaltenden Sprache scheint außergewöhnlich untypisch.

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Außerdem "versucht" try nichts. Es ist ein "Schutzrelais". Wenn die grundlegende Semantik des Vorschlags nicht stimmt, überrascht es mich nicht, dass der resultierende Code ebenfalls problematisch ist.

func (f *http2Framer) endWrite() error {
        ...
        relay n := f.w.Write(f.wbuf)
        return checkShortWrite(n, len(f.wbuf))
}

Wenn Sie eine try-Anweisung machen, können Sie mit einem Flag angeben, welcher Rückgabewert und welche Aktion ausgeführt wird:

try c, @      := newRawConn(fd) // return
try c, <strong i="6">@panic</strong> := newRawConn(fd) // panic
try c, <strong i="7">@hname</strong> := newRawConn(fd) // invoke named handler
try c, <strong i="8">@_</strong>     := newRawConn(fd) // ignore, or invoke "ignored" handler if defined

Sie benötigen immer noch eine Unterausdruckssyntax (Russ hat angegeben, dass dies eine Voraussetzung ist), zumindest für Panik- und Ignorieren-Aktionen.

Zunächst begrüße ich @crawshaw dafür, dass er sich die Zeit genommen hat, sich ungefähr 200 echte Beispiele anzusehen, und sich die Zeit für seinen durchdachten Artikel oben genommen hat.

Zweitens @jimmyfrasche bezüglich Ihrer Antwort hier zum http2Framer -Beispiel:

Ich habe mit mir selbst darüber diskutiert, ob if try legal sein würde oder sollte, aber ich konnte keine vernünftige Erklärung finden, warum es nicht sein sollte, und hier funktioniert es ganz gut:

```
func (f *http2Framer) endWrite() Fehler {
...
if try n := fwWrite(f.wbuf); n != len(f.wbuf) {
gib io.ErrShortWrite zurück
}
Null zurückgeben
}

At least under what I was suggesting above in https://github.com/golang/go/issues/32437#issuecomment-500213884, under that proposal variation I would suggest `if try` is not allowed.

That `http2Framer` example could instead be:

func (f *http2Framer) endWrite() Fehler {
...
try n := fwWrite(f.wbuf)
if n != len(f.wbuf) {
gib io.ErrShortWrite zurück
}
Null zurückgeben
}
`` That is one line longer, but hopefully still "light on the page". Personally, I think that (arguably) reads more cleanly, but more importantly it is easier to see the versuchen`.

@deanveloper schrieb oben in https://github.com/golang/go/issues/32437#issuecomment -498932961:

Die Rückkehr von einer Veranstaltung schien eine „heilige“ Sache gewesen zu sein

Dieses spezifische http2Framer -Beispiel ist am Ende nicht so kurz, wie es möglicherweise sein könnte. Es gilt jedoch, von einer "heiligeren" Funktion zurückzukehren, wenn try das erste Ding in einer Zeile sein muss.

@crawshaw erwähnt:

Die zweite Sache ist, dass nur sehr wenige von ihnen, weniger als 1 von 10, try in einen anderen Ausdruck einfügen würden. Der typische Fall sind Anweisungen der Form x := try(...) oder ^try(...)$.

Vielleicht ist es in Ordnung, diesen 1 von 10 Beispielen nur teilweise mit einer eingeschränkteren Form von try zu helfen, insbesondere wenn der typische Fall aus diesen Beispielen mit der gleichen Zeilenzahl endet, selbst wenn try ist muss das Erste in einer Linie sein?

@jimmyfrasche

@crawshaw danke dafür, es war toll, es in Aktion zu sehen. Aber als ich es in Aktion sah, nahm ich die Argumente gegen die Inline-Fehlerbehandlung, die ich bisher zurückgewiesen hatte, ernster.

Da dies in so unmittelbarer Nähe zu @thepudds interessantem Vorschlag war, try zu einer Aussage zu machen, habe ich alle Beispiele mit dieser Syntax neu geschrieben und fand sie viel klarer als entweder den Ausdruck - try oder den Status quo, ohne dass zu viele zusätzliche Zeilen erforderlich sind:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

Ihr erstes Beispiel veranschaulicht gut, warum ich den Ausdruck try stark bevorzuge. In Ihrer Version muss ich das Ergebnis des Aufrufs von le in eine Variable einfügen, aber diese Variable hat keine semantische Bedeutung, die der Begriff le nicht bereits impliziert. Ich kann ihm also keinen Namen geben, der nicht bedeutungslos (wie x ) oder überflüssig (wie lessOrEqual ) ist. Mit expression- try wird keine Zwischenvariable benötigt, sodass dieses Problem gar nicht erst auftritt.

Ich möchte lieber keine geistige Anstrengung aufwenden, um Namen für Dinge zu erfinden, die besser anonym bleiben.

Ich freue mich, meine Unterstützung hinter die letzten Posts zu werfen, in denen try (das Schlüsselwort) an den Anfang der Zeile verschoben wurde. Es sollte wirklich den gleichen visuellen Raum wie return .

Betreff: @jimmyfrasches Vorschlag, try in zusammengesetzten if -Anweisungen zuzulassen, das ist genau das, was meiner Meinung nach viele hier aus mehreren Gründen zu vermeiden versuchen:

• Es vereint zwei sehr unterschiedliche Kontrollflussmechanismen in einer einzigen Zeile
• Der try -Ausdruck wird tatsächlich zuerst ausgewertet und kann dazu führen, dass die Funktion zurückkehrt, aber er erscheint nach if
• Sie kehren mit völlig anderen Fehlern zurück, von denen wir einen nicht im Code sehen und einen, den wir sehen
• es macht es weniger offensichtlich, dass das try tatsächlich unbehandelt ist, da der Block einem Handler-Block sehr ähnlich sieht (obwohl er ein völlig anderes Problem behandelt).

Man könnte diese Situation aus einem etwas anderen Blickwinkel angehen, der es bevorzugt, die Leute dazu zu drängen, mit try s umzugehen. Wie wäre es, wenn Sie der Syntax try / else erlauben, nachfolgende Bedingungen zu enthalten (was ein häufiges Muster bei vielen E/A-Funktionen ist, die sowohl err als auch n zurückgeben

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf) else err {
                return errors.Wrap(err, "error writing:")
        } else if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

In dem Fall, in dem Sie den von .Write zurückgegebenen Fehler nicht behandeln, haben Sie immer noch eine klare Anmerkung, dass .Write einen Fehler verursachen könnte (wie von @thepudds hervorgehoben):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Ich schließe mich der Antwort von @daved an. Meiner Meinung nach wurde jedes Beispiel, das @crawshaw hervorgehoben hat, durch try weniger klar und fehleranfälliger.

Ich freue mich, meine Unterstützung hinter die letzten Posts zu werfen, in denen try (das Schlüsselwort) an den Anfang der Zeile verschoben wurde. Es sollte wirklich den gleichen visuellen Raum wie return .

Angesichts der beiden Optionen für diesen Punkt und unter der Annahme, dass eine ausgewählt wurde, und damit eine Art Präzedenzfall für zukünftige potenzielle Funktionen:

EIN.)

try f := os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

B.)

f := try os.Open(filepath) else err {
    return errors.Wrap(err, "can't open")
}

Welche der beiden bieten mehr Flexibilität für die zukünftige Verwendung neuer Keywords? _(Ich kenne die Antwort darauf nicht, da ich die dunkle Kunst des Schreibens von Compilern nicht gemeistert habe.)_ Wäre ein Ansatz einschränkender als ein anderer?

@davecheney @daved @crawshaw
Ich würde den Daves in diesem Punkt eher zustimmen: In den Beispielen von @crawshaw gibt es viele try -Anweisungen, die tief in Zeilen eingebettet sind, in denen eine Menge anderer Dinge vor sich gehen. Wirklich schwer zu erkennende Austrittspunkte. Außerdem scheinen die try -Parens in einigen Beispielen die Dinge ziemlich unübersichtlich zu machen.

Es ist sehr nützlich, einen Haufen stdlib-Code zu sehen, der so transformiert wurde, also habe ich die gleichen Beispiele genommen, sie aber gemäß dem alternativen Vorschlag neu geschrieben, der restriktiver ist:

• try als Schlüsselwort
• nur ein try pro Zeile
• try muss am Anfang einer Zeile stehen

Hoffentlich hilft uns das beim Vergleich. Ich persönlich finde, dass diese Beispiele viel prägnanter aussehen als ihre Originale, ohne jedoch den Kontrollfluss zu verdecken. try bleibt überall dort, wo es verwendet wird, gut sichtbar.

Text/Vorlage

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        lessOrEqual, err := le(arg1, arg2)
        if err != nil {
                return false, err
        }
        return !lessOrEqual, nil
}

wird:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

Text/Vorlage

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
...
        switch v.Kind() {
        case reflect.Map:
                index, err := prepareArg(index, v.Type().Key())
                if err != nil {
                        return reflect.Value{}, err
                }
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

wird

func index(item reflect.Value, indices ...reflect.Value) (reflect.Value, error) {
        ...
        switch v.Kind() {
        case reflect.Map:
                try index := prepareArg(index, v.Type().Key())
                if x := v.MapIndex(index); x.IsValid() {
                        v = x
                } else {
                        v = reflect.Zero(v.Type().Elem())
                }
        ...
        }
}

regulärer Ausdruck/Syntax:

regexp/syntax/parse.go

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        if c, t, err = nextRune(t); err != nil {
                return nil, err
        }
        p.literal(c)
        ...
}

wird

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

net/http

net/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

wird:

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

Datenbank/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

wird

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

Datenbank/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

wird

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

net/http

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                cc, err := p.t.dialclientconn(addr, singleuse)
                if err != nil {
                        return nil, err
                }
                return cc, nil
        }

wird

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                try cc := p.t.dialclientconn(addr, singleuse)
                return cc, nil
        }

net/http
Dieser erspart uns eigentlich keine Zeilen, aber ich finde ihn viel klarer, weil if err == nil eine relativ ungewöhnliche Konstruktion ist.

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

wird

func (f *http2Framer) endWrite() error {
        ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

net/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

wird

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
}

Netz:

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

wird

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@james-lawrence Als Antwort auf https://github.com/golang/go/issues/32437#issuecomment -500116099 : Ich erinnere mich nicht, dass Ideen wie ein optionales , err ernsthaft in Betracht gezogen wurden, nein. Ich persönlich halte das für eine schlechte Idee, weil es bedeutet, dass, wenn sich eine Funktion ändert, um einen nachgestellten error -Parameter hinzuzufügen, vorhandener Code weiter kompiliert wird, sich aber ganz anders verhält.

Die Verwendung von defer zur Behandlung der Fehler ist sehr sinnvoll, führt jedoch dazu, dass der Fehler benannt werden muss und eine neue Art von if err != nil -Boilerplate entsteht.

Externe Handler müssen dies tun:

func handler(err *error) {
  if *err != nil {
    *err = handle(*err)
  }
} 

die verwendet wird wie

defer handler(&err)

Externe Handler müssen nur einmal geschrieben werden, aber es müssten zwei Versionen vieler Fehlerbehandlungsfunktionen vorhanden sein: diejenige, die zurückgestellt werden soll, und diejenige, die auf normale Weise verwendet werden soll.

Interne Handler müssen dies tun:

defer func() {
  if err != nil {
    err = handle(err)
  }
}()

In beiden Fällen muss der Fehler der äußeren Funktion benannt werden, damit darauf zugegriffen werden kann.

Wie ich bereits erwähnt habe, kann dies in einer einzigen Funktion abstrahiert werden:

func catch(err *error, handle func(error) error) {
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

Das widerspricht @griesemers Besorgnis über die Mehrdeutigkeit von nil -Handler-Funktionen und hat seine eigenen defer - und func(err error) error -Boilerplates, zusätzlich zu der Notwendigkeit, err zu benennen

Wenn try als Schlüsselwort endet, kann es sinnvoll sein, auch ein catch -Schlüsselwort zu haben, das unten beschrieben wird.

Syntaktisch wäre es ähnlich wie handle :

catch err {
  return handleThe(err)
}

Semantisch wäre es Zucker für den obigen internen Handler-Code:

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

Da es etwas magisch ist, könnte es den Fehler der äußeren Funktion erfassen, selbst wenn er nicht benannt wurde. (Das err nach catch ist eher wie ein Parametername für den Block catch ).

catch hätte die gleiche Einschränkung wie try , dass es sich in einer Funktion befinden muss, die eine endgültige Fehlerrückgabe hat, da beide Zucker sind, die sich darauf verlassen.

Das ist bei weitem nicht so leistungsfähig wie der ursprüngliche handle -Vorschlag, aber es würde die Anforderung vermeiden, einen Fehler zu benennen, um ihn zu behandeln, und es würde die oben besprochene neue Textbausteine ​​für interne Handler entfernen, während es einfach genug wäre, dies nicht zu tun erfordern separate Versionen von Funktionen für externe Handler.

Eine komplizierte Fehlerbehandlung kann erfordern, dass catch nicht verwendet wird, genauso wie es möglicherweise erforderlich ist, try nicht zu verwenden.

Da es sich bei beiden um Zucker handelt, ist es nicht erforderlich, catch mit try zu verwenden. Die catch -Handler werden immer dann ausgeführt, wenn die Funktion einen Nicht- nil -Fehler zurückgibt, was beispielsweise das Einfügen einer schnellen Protokollierung ermöglicht:

catch err {
  log.Print(err)
  return err
}

oder packen Sie einfach alle zurückgegebenen Fehler ein:

catch err {
  return fmt.Errorf("foo: %w", err)
}

@ianlancetaylor

_" Ich denke, es ist eine schlechte Idee, weil es bedeutet, dass, wenn sich eine Funktion ändert, um einen nachgestellten error -Parameter hinzuzufügen, vorhandener Code weiter kompiliert wird, sich aber ganz anders verhält."_

Dies ist wahrscheinlich die richtige Betrachtungsweise, wenn Sie sowohl den Upstream- als auch den Downstream-Code steuern können, sodass Sie dies tun können, wenn Sie eine Funktionssignatur ändern müssen, um auch einen Fehler zurückzugeben.

Aber ich möchte Sie bitten, darüber nachzudenken, was passiert, wenn jemand weder vor- noch nachgelagert seine eigenen Pakete kontrolliert? Und auch die Anwendungsfälle zu berücksichtigen, in denen Fehler hinzugefügt werden könnten, und was passiert, wenn Fehler hinzugefügt werden müssen, Sie aber keine Änderung des nachgelagerten Codes erzwingen können?

Können Sie sich ein Beispiel vorstellen, bei dem jemand die Signatur ändern würde, um einen Rückgabewert hinzuzufügen? Für mich fallen sie typischerweise in die Kategorie _"Ich wusste nicht, dass ein Fehler auftreten würde"_ oder _"Ich fühle mich faul und möchte mich nicht anstrengen, weil der Fehler wahrscheinlich nicht passieren wird." _

In beiden Fällen kann ich eine Fehlerrückgabe hinzufügen, da sich herausstellt, dass ein Fehler behandelt werden muss. Was kann ich in diesem Fall tun, wenn ich die Signatur nicht ändern kann, weil ich die Kompatibilität für andere Entwickler, die meine Pakete verwenden, nicht beeinträchtigen möchte? Ich vermute, dass der Fehler in den allermeisten Fällen auftritt und dass der Code, der die Funktion aufgerufen hat, die den Fehler nicht zurückgibt, sich _wie auch immer_ ganz anders verhält.

Eigentlich mache ich letzteres selten, aber zu häufig mache ich ersteres. Aber ich habe bemerkt, dass Pakete von Drittanbietern häufig Erfassungsfehler ignorieren, wo sie sein sollten, und ich weiß das, weil, wenn ich ihren Code in GoLand aufrufe, jedes Mal leuchtend orange markiert wird. Ich würde gerne Pull-Requests einreichen, um den Paketen, die ich häufig verwende, eine Fehlerbehandlung hinzuzufügen, aber wenn ich das tue, werden sie von den meisten nicht akzeptiert, weil ich ihre Code-Signaturen brechen würde.

Da keine abwärtskompatible Methode zum Hinzufügen von Fehlern angeboten wird, die von Funktionen zurückgegeben werden sollen, können Entwickler, die Code verteilen und darauf achten, dass nichts für ihre Benutzer beschädigt wird, ihre Pakete nicht so weiterentwickeln, dass sie die Fehlerbehandlung enthalten, wie sie sollten.

Anstatt das Problem darin zu sehen, dass sich der Code anders verhält, sollten Sie das Problem vielleicht als eine technische Herausforderung betrachten, wie der Nachteil einer Methode minimiert werden kann, die einen Fehler nicht aktiv erfasst. Das hätte einen breiteren und längerfristigen Wert.

Ziehen Sie beispielsweise in Betracht, einen Paketfehlerhandler hinzuzufügen, den man festlegen muss, bevor Fehler ignoriert werden können?

Um ehrlich zu sein, war Gos Idiom, Fehler zusätzlich zu den regulären Rückgabewerten zurückzugeben, eine seiner besseren Innovationen. Aber wie so oft, wenn man Dinge verbessert, legt man oft andere Schwächen offen, und ich werde argumentieren, dass die Fehlerbehandlung von Go nicht innovativ genug war.

Wir Gophers sind darauf versessen, einen Fehler zurückzugeben, anstatt eine Ausnahme auszulösen, daher lautet meine Frage: „Warum sollten wir nicht Fehler von jeder Funktion zurückgeben?“_ Wir tun dies nicht immer, weil das Schreiben von Code ohne Fehlerbehandlung es ist bequemer als damit zu codieren. Also lassen wir die Fehlerbehandlung weg, wenn wir glauben, dass wir davon wegkommen können. Aber häufig raten wir falsch.

Also wirklich, wenn es möglich wäre, den Code elegant und lesbar zu machen, würde ich argumentieren, dass Rückgabewerte und Fehler wirklich getrennt behandelt werden sollten und dass _jede_ Funktion die Fähigkeit haben sollte, Fehler unabhängig von ihren früheren Funktionssignaturen zurückzugeben. Und es wäre ein lohnendes Unterfangen, vorhandenen Code dazu zu bringen, Code, der jetzt Fehler erzeugt, ordnungsgemäß zu handhaben.

Ich habe nichts vorgeschlagen, weil ich mir keine praktikable Syntax vorstellen konnte, aber wenn wir ehrlich zu uns selbst sein wollen, drehte sich nicht alles in diesem Thread und im Zusammenhang mit der Fehlerbehandlung von Go im Allgemeinen um die Tatsache, dass die Fehlerbehandlung und Programmlogik sind seltsame Bettgenossen, also würden Fehler im Idealfall am besten auf irgendeine Weise außerhalb des Bandes behandelt werden?

try als Schlüsselwort hilft sicherlich bei der Lesbarkeit (im Vergleich zu einem Funktionsaufruf) und scheint weniger komplex zu sein. @brynbellomy @crawshaw danke, dass du dir die Zeit genommen hast, die Beispiele aufzuschreiben.

Ich nehme an, mein allgemeiner Gedanke ist, dass try zu viel bewirkt. Es löst: Funktion aufrufen, Variablen zuweisen, Fehler überprüfen und Fehler zurückgeben, falls vorhanden. Ich schlage vor, dass wir stattdessen den Bereich abschneiden und nur für die bedingte Rückgabe auflösen: "Rückgabe, wenn letztes Argument nicht nil".

Dies ist wahrscheinlich keine neue Idee ... Aber nachdem ich die Vorschläge im Fehler-Feedback-Wiki überflogen habe, habe ich sie nicht gefunden (bedeutet nicht, dass sie nicht vorhanden ist).

Mini-Vorschlag zur bedingten Rückgabe

Auszug:

err, thing := newThing(name)
refuse nil, err

Ich habe es auch im Wiki unter "Alternative Ideen" hinzugefügt.

Nichts zu tun scheint auch eine sehr vernünftige Option zu sein.

@alexhornbake , das gibt mir eine etwas andere Idee, die nützlicher wäre

assert(nil, err)
assert(len(a), len(b))
assert(true, condition)
assert(expected, given)

Auf diese Weise würde es nicht nur für die Fehlerprüfung gelten, sondern für viele Arten von Logikfehlern.

Das Gegebene würde in einen Fehler eingeschlossen und zurückgegeben.

@alexhornbach

Genauso wie try es nicht wirklich versucht, ist refuse nicht wirklich „verweigernd“. Die gemeinsame Absicht hier war, dass wir ein "Schutzrelais" setzen ( relay ist kurz, genau und alliteratives Wort für return ), das "auslöst", wenn einer der verdrahteten Werte eine Bedingung erfüllt (dh ist ein Nicht-Null-Fehler). Es ist eine Art Leistungsschalter und kann meiner Meinung nach einen Mehrwert schaffen, wenn sein Design auf uninteressante Fälle beschränkt wäre, um einfach einige der am niedrigsten hängenden Boilerplates zu reduzieren. Alles, was auch nur annähernd komplex ist, sollte sich auf einfachen Go-Code verlassen.

Ich empfehle Cranshaw auch für seine Arbeit beim Durchsuchen der Standardbibliothek, aber ich bin zu einem ganz anderen Schluss gekommen ... Ich denke, es macht fast alle diese Codeschnipsel schwieriger zu lesen und anfälliger für Missverständnisse.

        req.Header = Header(try(tp.ReadMIMEHeader())

Ich werde sehr oft vermissen, dass dies zu Fehlern führen kann. Ein schnelles Lesen bringt mich zu "ok, setze den Header auf Header von ReadMimeHeader des Dings".

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

Bei diesem hier kreuzen sich meine Augen beim Versuch, diese OpenDB-Zeile zu analysieren. Da ist so viel Dichte ... Das zeigt das Hauptproblem, das alle verschachtelten Funktionsaufrufe haben, nämlich dass Sie von innen nach außen lesen müssen, und Sie müssen es in Ihrem Kopf analysieren, um herauszufinden, wo der innerste Teil ist .

Beachten Sie auch, dass dies von zwei verschiedenen Stellen in derselben Zeile zurückkehren kann ... Sie werden debuggen, und es wird sagen, dass von dieser Zeile ein Fehler zurückgegeben wurde, und das erste, was jeder tun wird, ist, es zu versuchen Finden Sie heraus, warum OpenDB mit diesem seltsamen Fehler fehlschlägt, wenn es tatsächlich OpenConnector ist (oder umgekehrt).

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }   

Dies ist eine Stelle, an der der Code versagen kann, wo dies zuvor unmöglich gewesen wäre. Ohne try kann die Konstruktion von Struct-Literalen nicht fehlschlagen . Meine Augen werden darüber schweifen wie „ok, einen Treiber erstellen Stmt ... weitermachen ...“ und es wird so leicht zu übersehen sein, dass dies tatsächlich dazu führen kann, dass Ihre Funktion fehlerhaft ist. Der einzige Weg, der vorher möglich gewesen wäre, wäre, wenn ctxDriverPrepare in Panik geraten wäre ... und wir alle wissen, dass dies ein Fall ist, der 1.) im Grunde nie passieren sollte und 2.) wenn dies der Fall ist, bedeutet dies, dass etwas drastisch falsch ist.

Wenn Sie ein Schlüsselwort und eine Anweisung ausprobieren, werden viele meiner Probleme damit behoben. Ich weiß, dass das nicht abwärtskompatibel ist, aber ich glaube nicht, dass die Verwendung einer schlechteren Version davon die Lösung für das Problem der Abwärtskompatibilität ist.

@daved Ich bin mir nicht sicher, ob ich folge. Magst du den Namen nicht oder magst du die Idee nicht?

Wie auch immer, ich habe das hier als Alternative gepostet ... Wenn es berechtigtes Interesse gibt, kann ich ein neues Thema zur Diskussion eröffnen, will diesen Thread nicht verschmutzen (vielleicht zu spät?) Daumen hoch / runter für die ursprüngliche Idee geben uns ein Gefühl... Natürlich offen für alternative Namen. Wichtiger Teil ist "bedingte Rückgabe, ohne zu versuchen, die Abtretung zu bearbeiten".

Obwohl mir der Fangvorschlag von @jimmyfrasche gefällt , möchte ich eine Alternative vorschlagen:
go handler fmt.HandleErrorf("copy %s %s", src, dst)
wäre gleichbedeutend mit:
go defer func(){ if(err != nil){ fmt.HandleErrorf(&err,"copy %s %s", src, dst) } }()
wobei err der zuletzt genannte Rückgabewert ist, mit Typ error. Handler können jedoch auch verwendet werden, wenn Rückgabewerte nicht benannt sind. Der allgemeinere Fall wäre auch erlaubt:
go handler func(err *error){ *err = fmt.Errorf("foo: %w", *err) }() `
Das Hauptproblem, das ich bei der Verwendung benannter Rückgabewerte habe (was catch nicht löst), ist, dass err überflüssig ist. Wenn ein Aufruf an einen Handler wie fmt.HandleErrorf wird, gibt es kein vernünftiges erstes Argument außer einem Zeiger auf den Fehlerrückgabewert. Warum dem Benutzer die Möglichkeit geben, einen Fehler zu machen?

Im Vergleich zu catch besteht der Hauptunterschied darin, dass handler das Aufrufen vordefinierter Handler etwas einfacher macht, auf Kosten einer ausführlicheren Definition, um sie an Ort und Stelle zu definieren. Ich bin mir nicht sicher, ob dies ideal ist, aber ich denke, es entspricht eher dem ursprünglichen Vorschlag.

@yiyus catch , wie ich es definiert habe, muss err nicht in der Funktion benannt werden, die die catch enthält.

In catch err { ist err der Name des Fehlers innerhalb des Blocks catch . Es ist wie ein Funktionsparametername.

Damit ist etwas wie fmt.HandleErrorf nicht mehr erforderlich, da Sie einfach das normale fmt.Errorf verwenden können:

func f() error {
  catch err {
    return fmt.Errorf("foo: %w", err)
  }
  return errors.New("bar")
}

was einen Fehler zurückgibt, der als foo: bar gedruckt wird.

Ich mag diesen Ansatz nicht, weil:

• Der Funktionsaufruf try() unterbricht die Codeausführung in der übergeordneten Funktion.
• es gibt kein Schlüsselwort return , aber der Code gibt tatsächlich zurück.

Es werden viele Möglichkeiten vorgeschlagen, Handler zu machen, aber ich denke, sie verfehlen oft zwei wichtige Anforderungen:

1. Es muss deutlich anders und besser sein als if x, err := thingie(); err != nil { handle(err) } . Ich denke, Vorschläge in der Art von try x := thingie else err { handle(err) } erfüllen diese Messlatte nicht. Warum sagst du nicht einfach if ?

2. Es sollte orthogonal zur bestehenden Funktionalität von defer sein. Das heißt, es sollte so unterschiedlich sein, dass klar ist, dass der vorgeschlagene Handhabungsmechanismus eigenständig benötigt wird, ohne seltsame Eckfälle zu erzeugen, wenn Handhabung und Zurückstellung interagieren.

Bitte beachten Sie diese Anforderungen, wenn wir alternative Mechanismen für try /Handle diskutieren.

@carlmjohnson Ich mag die catch -Idee von @jimmyfrasche in Bezug auf Ihren Punkt 2 - es ist nur Syntaxzucker für ein defer , der 2 Zeilen spart und es Ihnen ermöglicht, den Fehlerrückgabewert zu benennen (was in an der Reihe würden Sie auch alle anderen benennen müssen, wenn Sie dies nicht bereits getan haben). Es wirft kein Orthogonalitätsproblem mit defer , weil es defer ist.

Wiederholen, was @ubombi gesagt hat:

Der Aufruf der Funktion try() unterbricht die Codeausführung in der übergeordneten Funktion.; es gibt kein return-Schlüsselwort, aber der Code kehrt tatsächlich zurück.

In Ruby sind Procs und Lambdas ein Beispiel dafür, was try tut ... Ein Proc ist ein Codeblock, dessen return-Anweisung nicht vom Block selbst, sondern vom Aufrufer zurückgegeben wird.

Das ist genau das, was try tut ... es ist nur eine vordefinierte Ruby-Prozedur.

Ich denke, wenn wir diesen Weg gehen würden, könnten wir den Benutzer vielleicht tatsächlich seine eigene try -Funktion definieren lassen, indem wir proc functions einführen

Ich bevorzuge immer noch if err != nil , weil es besser lesbar ist, aber ich denke, try wäre vorteilhafter, wenn der Benutzer seine eigene Prozedur definieren würde:

proc try(err *error, msg string) {
  if *err != nil {
    *err = fmt.Errorf("%v: %w", msg, *err)
    return
  }
}

Und dann kannst du es nennen:

func someFunc() (string, error) {
  err := doSomething()
  try(&err, "someFunc failed")
}

Der Vorteil dabei ist, dass Sie die Fehlerbehandlung nach Ihren eigenen Vorstellungen definieren können. Und Sie können auch ein proc exponiert, privat oder intern machen.

Es ist auch besser als die handle {} -Klausel im ursprünglichen Go2-Vorschlag, da Sie dies nur einmal für die gesamte Codebasis und nicht in jeder Funktion definieren können.

Eine Überlegung für die Lesbarkeit ist, dass ein func() und ein proc() unterschiedlich aufgerufen werden können, wie z. B. func() und proc!() , damit ein Programmierer weiß, dass ein proc-Aufruf tatsächlich aus dem zurückkehren könnte aufrufende Funktion.

@marwan-at-work, sollte try(err, "someFunc failed") try(&err, "someFunc failed") in deinem Beispiel nicht try(&err, "someFunc failed") sein?

@dpinela danke für die Korrektur, Code aktualisiert :)

Die gängige Praxis, die wir hier zu überschreiben versuchen, ist das, was das Standard-Stack-Unwinding in vielen Sprachen in einer Ausnahme vorschlägt (und daher wurde das Wort "versuchen" ausgewählt ...).
Aber wenn wir nur eine Funktion (...try() oder andere) zulassen könnten, die im Trace zwei Ebenen zurückspringen würde, dann

try := handler(err error) {     //which corelates with - try := func(err error) 
   if err !=nil{
       //do what ever you want to do when there's an error... log/print etc
       return2   //2 levels
   }
} 

und dann ein Code wie
f := try(os.Open(Dateiname))
könnte genau das tun, was der Vorschlag empfiehlt, aber da es sich um eine Funktion (oder eigentlich eine "Handler-Funktion") handelt, hat der Entwickler viel mehr Kontrolle darüber, was die Funktion tut, wie sie den Fehler in verschiedenen Fällen formatiert, und verwendet überall einen ähnlichen Handler der Code, um (sagen wir) os.Open zu handhaben, anstatt jedes Mal fmt.Errorf("Fehler beim Öffnen der Datei %s ....") zu schreiben.
Dies würde auch eine Fehlerbehandlung erzwingen, als ob "try" nicht definiert wäre - es ist ein Kompilierzeitfehler.

@guybrand Eine solche zweistufige Rückgabe return2 (oder "nicht lokale Rückgabe", wie das allgemeine Konzept in Smalltalk genannt wird) wäre ein netter Allzweckmechanismus (ebenfalls vorgeschlagen von @mikeschinkel in #32473). . Aber es scheint, dass try in Ihrem Vorschlag noch benötigt wird, daher sehe ich keinen Grund für return2 - try kann nur return tun try schreiben könnte, aber das geht bei beliebigen Signaturen nicht.

@griesemer

_"Also sehe ich keinen Grund für das return2 - das try kann einfach das return tun."_

Ein Grund – wie ich in #32473 _(danke für den Hinweis)_ erwähnt habe – wäre, mehrere Ebenen von break und continue zusätzlich zu return zuzulassen.

Nochmals vielen Dank an alle für all die neuen Kommentare; Es ist eine erhebliche Zeitinvestition, um mit der Diskussion Schritt zu halten und umfangreiches Feedback zu verfassen. Und besser noch, trotz der manchmal leidenschaftlichen Auseinandersetzungen war dies bisher ein eher ziviler Thread. Danke!

Hier ist eine weitere kurze Zusammenfassung, diesmal etwas komprimierter; Entschuldigung an diejenigen, die ich nicht erwähnt, vergessen oder falsch dargestellt habe. An diesem Punkt denke ich, dass sich einige größere Themen abzeichnen:

1) Im Allgemeinen wird die Verwendung eines eingebauten für die try -Funktionalität als schlechte Wahl empfunden: Angesichts der Tatsache, dass es den Kontrollfluss beeinflusst, sollte es _mindestens_ ein Schlüsselwort sein ( @carloslenz "bevorzugt eine Anweisung ohne Klammer"); try als Ausdruck scheint keine gute Idee zu sein, es schadet der Lesbarkeit ( @ChrisHines , @jimmyfrasche), sie sind "Rückgaben ohne return ". @brynbellomy führte eine aktuelle Analyse von try durch, die als Identifikatoren verwendet wurden; es scheint prozentual nur sehr wenige zu geben, so dass es möglich sein könnte, die Keyword-Route zu gehen, ohne zu viel Code zu beeinflussen.

2) @crawshaw brauchte einige Zeit, um ein paar hundert Anwendungsfälle aus der std-Bibliothek zu analysieren, und kam zu dem Schluss, dass try wie vorgeschlagen fast immer die Lesbarkeit verbesserte. @jimmyfrasche kam zum gegenteiligen Ergebnis.

3) Ein weiteres Thema ist, dass die Verwendung defer für die Fehlerdekoration nicht ideal ist. @josharian weist darauf hin, dass die defer immer bei Funktionsrückgabe ausgeführt werden, aber wenn sie zur Fehlerdekoration hier sind, kümmern wir uns nur um ihren Körper, wenn ein Fehler vorliegt, was zu Verwirrung führen könnte.

4) Viele schrieben Vorschläge zur Verbesserung des Vorschlags. @zeebo , @patrick-nyt unterstützen die gofmt Formatierung einfacher if Anweisungen in einer einzigen Zeile (und sind mit dem Status quo zufrieden). @jargv schlug vor, dass try() (ohne Argumente) einen Zeiger auf den aktuell "ausstehenden" Fehler zurückgeben könnte, was die Notwendigkeit beseitigen würde, das Fehlerergebnis zu benennen, nur damit man in einem defer Zugriff darauf hat @masterada schlug vor, stattdessen errorfunc() zu verwenden. @velovix hat die Idee eines 2-Argumentes try wiederbelebt, wobei das 2. Argument ein Fehlerbehandler wäre.

@klaidliadon , @networkimprov sind für spezielle "Zuweisungsoperatoren" wie in f, # := os.Open() statt try . @networkimprov reichte einen umfassenderen Alternativvorschlag ein, der solche Ansätze untersucht (siehe Ausgabe Nr. 32500). @mikeschinkel reichte auch einen alternativen Vorschlag ein, der vorschlug, zwei neue Allzweck-Sprachfunktionen einzuführen, die auch für die Fehlerbehandlung verwendet werden könnten, anstelle eines fehlerspezifischen try (siehe Ausgabe Nr. 32473). @josharian hat eine Möglichkeit wiederbelebt, die wir letztes Jahr auf der GopherCon besprochen haben, wo try bei einem Fehler nicht zurückkehrt, sondern stattdessen (mit einem goto ) zu einem Label namens error springt (alternativ , try könnte den Namen eines Ziellabels annehmen).

5) Zum Thema try als Schlüsselwort sind zwei Gedankengänge aufgetaucht. @brynbellomy schlug eine Version vor, die alternativ einen Handler angeben könnte:

a, b := try f()
a, b := try f() else err { /* handle error */ }

@thepudds geht noch einen Schritt weiter und schlägt try am Anfang der Zeile vor, wodurch try die gleiche Sichtbarkeit erhält wie return :

try a, b := f()

Beides könnte mit defer funktionieren.

@griesemer

Danke für den Verweis auf @mikeschinkel #32473, es hat viel gemeinsam.

bezüglich

Aber es scheint, dass in Ihrem Vorschlag noch ein Versuch erforderlich ist
Obwohl mein Vorschlag mit "jedem" Handler und nicht mit einem reservierten "build in/keyword/expression" implementiert werden kann, halte ich "try()" nicht für eine schlechte Idee (und habe es daher nicht abgelehnt), ich versuche es um es zu "erweitern" - damit es mehr Vorteile zeigt, viele erwarteten "einmal 2.0 wird eingeführt"

Ich denke, das könnte auch die Quelle der "gemischten Schwingungen" sein, die Sie in Ihrer letzten Zusammenfassung gemeldet haben - es ist nicht "try() verbessert die Fehlerbehandlung nicht" - sicher, es tut es, es "wartet darauf, dass Go 3.0 einen anderen schwerwiegenden Fehler behebt Umgang mit Schmerzen", wie oben angegeben, sieht zu lang aus :)

Ich führe eine Umfrage zu „Problemen bei der Fehlerbehandlung“ durch (und stelle fest, dass einige der Probleme lediglich „Ich verwende keine guten Praktiken“ sind, während ich mir bei einigen nicht einmal vorgestellt habe, dass Leute (meistens aus anderen Sprachen) dies tun möchten – von cool zu WTF).

Ich hoffe, ich kann bald einige interessante Ergebnisse teilen.

Zum Schluss -Danke für die tolle Arbeit und Geduld!

Betrachtet man einfach die Länge der derzeit vorgeschlagenen Syntax im Vergleich zu dem, was jetzt verfügbar ist, ist der Fall, in dem der Fehler nur zurückgegeben werden muss, ohne ihn zu behandeln oder zu dekorieren, der Fall, in dem der größte Komfort erzielt wird. Ein Beispiel mit meiner bisherigen Lieblingssyntax:

try a, b := f() else err { return fmt.Errorf("Decorated: %s", err); }
if a,b, err :=f;  err != nil { return fmt.Errorf("Decorated: %s", err); }
try a, b := f()
if a,b, err :=f;  err != nil { return err; }

Also, anders als ich vorher dachte, reicht es vielleicht einfach, go fmt zu ändern, zumindest für den dekorierten/behandelten Fehlerfall. Während für das einfache Weitergeben des Fehlerfalls so etwas wie Versuch als syntaktischer Zucker für diesen sehr häufigen Anwendungsfall wünschenswert sein könnte.

In Bezug auf try else denke ich, dass bedingte Fehlerfunktionen wie fmt.HandleErrorf (Bearbeiten: Ich gehe davon aus, dass es nil zurückgibt, wenn die Eingabe nil ist) im ersten Kommentar gut funktionieren, also fügen Sie else hinzu ist unnötig.

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

Wie viele andere hier ziehe ich es vor, dass try eine Anweisung und kein Ausdruck ist, vor allem, weil ein Ausdruck, der den Kontrollfluss verändert, Go völlig fremd ist. Da dies kein Ausdruck ist, sollte es am Anfang der Zeile stehen.

Ich stimme auch @daved zu, dass der Name nicht angemessen ist. Schließlich versuchen wir hier, eine geschützte Zuweisung zu erreichen. Warum also nicht wie in Swift guard verwenden und die Klausel else optional machen? Etwas wie

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

wobei Identifier der Name der Fehlervariablen ist, die im folgenden Block gebunden ist. Ohne else -Klausel kehren Sie einfach von der aktuellen Funktion zurück (und verwenden Sie einen Defer-Handler, um bei Bedarf Fehler zu dekorieren).

Anfangs mochte ich eine else Klausel nicht, weil es nur syntaktischer Zucker um die übliche Zuweisung herum ist, gefolgt von if err != nil , aber nachdem ich einige der Beispiele gesehen habe, macht es einfach Sinn: guard zu verwenden

BEARBEITEN: Einige schlugen vor, Dinge wie catch zu verwenden, um irgendwie verschiedene Fehlerhandler anzugeben. Ich finde else semantisch genauso brauchbar und es ist bereits in der Sprache enthalten.

Ich mag zwar die try-else-Anweisung, aber wie wäre es mit dieser Syntax?

a, b, (err) := func() else { return err }

Ausdruck try - else ist ein ternärer Operator.

a, b := try f() else err { ... }
fmt.Println(try g() else err { ... })`

Die Anweisung try - else ist eine if -Anweisung.

try a, b := f() else err { ... }
// (modulo scope of err) same as
a, b, err := f()
if err != nil { ... }

Das eingebaute try mit einem optionalen Handler kann entweder mit einer Hilfsfunktion (unten) oder ohne Verwendung try erreicht werden (nicht abgebildet, wir alle wissen, wie das aussieht).

a, b := try(f(), decorate)
// same as
a, b := try(g())
// where g is
func g() (whatever, error) {
  x, err := f()
  if err != nil {
    try(decorate(err))
  }
  return x, nil
}

Alle drei reduzieren den Textbaustein und helfen, den Umfang der Fehler einzudämmen.

Es gibt die meisten Einsparungen für eingebaute try , aber das hat die Probleme, die im Designdokument erwähnt werden.

Für die Anweisung try - else bietet sie einen Vorteil gegenüber der Verwendung if anstelle von try . Aber der Vorteil ist so marginal, dass ich es schwer finde, ihn zu rechtfertigen, obwohl ich ihn mag.

Alle drei gehen davon aus, dass es üblich ist, für einzelne Fehler eine spezielle Fehlerbehandlung zu benötigen.

Die Behandlung aller Fehler kann in defer gleich behandelt werden. Wenn in jedem else -Block dieselbe Fehlerbehandlung durchgeführt wird, wiederholt sich das etwas:

func printSum(a, b string) error {
  try x := strconv.Atoi(a) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  try y := strconv.Atoi(b) else err {
    return fmt.Errorf("printSum: %w", err)
  }
  fmt.Println("result:", x + y)
  return nil
}

Ich weiß sicherlich, dass es Zeiten gibt, in denen ein bestimmter Fehler eine besondere Behandlung erfordert. Das sind die Fälle, die mir in Erinnerung geblieben sind. Aber wenn das nur passiert, sagen wir, 1 von 100 Mal, wäre es nicht besser, try einfach zu halten und try in solchen Situationen einfach nicht zu verwenden? Wenn es andererseits eher 1 von 10 Mal ist, erscheint das Hinzufügen else /handler sinnvoller.

Es wäre jedoch interessant zu sehen, wie oft try ohne else /Handler vs. try mit else /Handler nützlich wäre das ist nicht einfach Daten zu sammeln.

Ich möchte den letzten Kommentar von @jimmyfrasche erweitern.

Das Ziel dieses Vorschlags ist es, die Boilerplate zu reduzieren

    a, b, err := f()
    if err != nil {
        return nil, err
    }

Dieser Code ist einfach zu lesen. Eine Erweiterung der Sprache lohnt sich nur, wenn wir eine deutliche Reduzierung der Boilerplate erreichen können. Wenn ich sowas sehe

    try a, b := f() else err { return nil, err }

Ich kann mich des Gefühls nicht erwehren, dass wir nicht so viel sparen. Wir sparen drei Zeilen ein, was gut ist, aber nach meiner Zählung reduzieren wir von 56 auf 46 Zeichen. Das ist nicht viel. Vergleichen mit

    a, b := try(f())

wodurch von 56 auf 18 Zeichen gekürzt wird, eine viel bedeutendere Reduzierung. Und während die try -Aussage die potenzielle Änderung des Kontrollflusses deutlicher macht, finde ich die Aussage insgesamt nicht lesbarer. Auf der positiven Seite macht es die try -Anweisung jedoch einfacher, den Fehler zu kommentieren.

Wie auch immer, mein Punkt ist: Wenn wir etwas ändern, sollte es die Boilerplate erheblich reduzieren oder deutlich besser lesbar sein. Letzteres ist ziemlich schwierig, daher muss jede Änderung wirklich an ersterem arbeiten. Wenn wir nur eine geringfügige Reduzierung der Boilerplate erhalten, lohnt es sich meiner Meinung nach nicht.

Wie andere möchte ich mich bei @crawshaw für die Beispiele bedanken.

Wenn Sie diese Beispiele lesen, ermutige ich die Leute, eine Denkweise anzunehmen, in der Sie sich keine Gedanken über den Kontrollfluss aufgrund der try -Funktion machen. Ich glaube, vielleicht zu Unrecht, dass dieser Kontrollfluss für Menschen, die die Sprache beherrschen, schnell zur zweiten Natur werden wird. Im Normalfall glaube ich, dass die Leute einfach aufhören werden, sich Gedanken darüber zu machen, was im Fehlerfall passiert. Versuchen Sie, diese Beispiele zu lesen, während Sie über try glasieren, so wie Sie bereits über if err != nil { return err } glasieren.

Nachdem ich hier alles durchgelesen habe und nach weiterem Nachdenken, bin ich mir nicht sicher, ob ich den Versuch auch nur als eine Aussage sehe, die es wert ist, hinzugefügt zu werden.

1. Der Grund dafür scheint die Reduzierung des Boilerplate-Codes für die Fehlerbehandlung zu sein. IMHO "entrümpelt" es den Code, aber es beseitigt nicht wirklich die Komplexität; es verdeckt es nur. Dies scheint kein stark genuger Grund zu sein. Das „Geh"Syntax schön eingefangen, wenn ich einen gleichzeitigen Thread starte. Ich bekomme hier nicht dieses "Aha!"-Gefühl. Es fühlt sich nicht richtig an. Das Kosten-Nutzen-Verhältnis ist nicht groß genug.

2. sein Name spiegelt nicht seine Funktion wider. In seiner einfachsten Form ist das folgende: "Wenn eine Funktion einen Fehler zurückgibt, kehre vom Aufrufer mit einem Fehler zurück", aber das ist zu lang :-) Zumindest wird ein anderer Name benötigt.

3. Mit der impliziten Rückgabe von try bei Fehlern fühlt es sich an, als würde Go nur widerwillig auf die Ausnahmebehandlung zurückgreifen. Das heißt, wenn A be in einem Try Guard aufruft und B C in einem Try Guard aufruft und C D in einem Try Guard aufruft, wenn D tatsächlich einen Fehler zurückgibt, haben Sie ein nicht lokales goto verursacht. Es fühlt sich zu "magisch" an.

4. und doch glaube ich, dass ein besserer Weg möglich sein könnte. Wenn Sie Jetzt versuchen auswählen, wird diese Option deaktiviert.

@ianlancetaylor
Wenn ich den Vorschlag "Versuche es sonst" richtig verstehe, scheint es, dass der Block else optional und für die vom Benutzer bereitgestellte Behandlung reserviert ist. In Ihrem Beispiel try a, b := f() else err { return nil, err } ist die Klausel else tatsächlich überflüssig, und der gesamte Ausdruck kann einfach als try a, b := f() geschrieben werden

Ich stimme @ianlancetaylor zu,
Lesbarkeit und Boilerplate sind zwei Hauptanliegen und vielleicht der Antrieb dazu
die Go 2.0-Fehlerbehandlung (obwohl ich einige andere wichtige Bedenken hinzufügen kann)

Auch dass die Strömung

a, b, err := f()
if err != nil {
    return nil, err
}

Ist sehr gut lesbar.
Und da glaube ich

if a, b, err := f(); err != nil {
    return nil, err
}

Ist fast so lesbar, hatte aber seinen Umfang "Probleme", vielleicht a

ifErr a, b, err := f() {
    return nil, err
}

Das wäre nur die ; err != nil part, und würde keinen Geltungsbereich erstellen, oder

ähnlich

versuche a, b, ähm := f() {
gib null zurück, äh
}

Behält die zusätzlichen zwei Zeilen bei, ist aber immer noch lesbar.

Am Di, 11. Juni 2019, 20:19 Uhr Dmitriy Matrenichev, [email protected]
schrieb:

@ianlancetaylor https://github.com/ianlancetaylor
Wenn ich den Vorschlag "Versuche es sonst" richtig verstehe, scheint es, als würde es sonst blockieren
ist optional und für die vom Benutzer bereitgestellte Handhabung reserviert. In deinem Beispiel
try a, b := f() else err { return nil, err } die else-Klausel ist tatsächlich
überflüssig, und der gesamte Ausdruck kann einfach als try a, b := geschrieben werden
F()

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXN3VDA#issuecomment-5009,39404
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALANCNFSM4HTGCZ7Q
.

@ianlancetaylor

Wie auch immer, mein Punkt ist: Wenn wir etwas ändern, sollte es die Boilerplate erheblich reduzieren oder deutlich besser lesbar sein. Letzteres ist ziemlich schwierig, daher muss jede Änderung wirklich an ersterem arbeiten. Wenn wir nur eine geringfügige Reduzierung der Boilerplate erhalten, lohnt es sich meiner Meinung nach nicht.

Einverstanden, und wenn man bedenkt, dass ein else nur syntaktischer Zucker (mit einer seltsamen Syntax!) wäre, der sehr wahrscheinlich nur selten verwendet wird, kümmere ich mich nicht viel darum. Ich würde es trotzdem vorziehen, wenn try eine Aussage wäre.

@ianlancetaylor In Anlehnung an @DmitriyMV wäre der Block else optional. Lassen Sie mich ein Beispiel anfügen, das beides veranschaulicht (und in Bezug auf den relativen Anteil von behandelten vs. nicht behandelten try -Blöcken in echtem Code nicht allzu weit daneben zu liegen scheint):

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    headRef, err := r.Head()
    if err != nil {
        return err
    }

    parentObjOne, err := headRef.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit)
    if err != nil {
        return err
    }

    parentCommitOne, err := parentObjOne.AsCommit()
    if err != nil {
        return err
    }

    parentCommitTwo, err := parentObjTwo.AsCommit()
    if err != nil {
        return err
    }

    treeOid, err := index.WriteTree()
    if err != nil {
        return err
    }

    tree, err := r.LookupTree(treeOid)
    if err != nil {
        return err
    }

    remoteBranchName, err := remoteBranch.Name()
    if err != nil {
        return err
    }

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    if err != nil {
        return err
    }
    return nil
}

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()
    try userName, userEmail := r.UserIdentityFromConfig() else err {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    try r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return nil
}

Das Muster try / else spart zwar nicht viele Zeichen gegenüber dem zusammengesetzten if , aber es tut es:

• Vereinheitlichen Sie die Fehlerbehandlungssyntax mit dem unbehandelten try
• machen auf einen Blick deutlich, dass ein Bedingungsblock eine Fehlerbedingung behandelt
• Geben Sie uns die Möglichkeit, die Scoping-Verrücktheit zu reduzieren, unter der die Verbindungen if leiden

Nicht gehandhabte try werden jedoch wahrscheinlich am häufigsten vorkommen.

@ianlancetaylor

Versuchen Sie, diese Beispiele zu lesen, während Sie über try glasieren, so wie Sie es bereits glasiert haben, wenn err != nil { return err }.

Ich halte das nicht für möglich/gleichwertig. Fehlen, dass ein Versuch in einer überfüllten Zeile vorhanden ist oder was genau umbrochen wird oder dass es mehrere Instanzen in einer Zeile gibt ... Dies ist nicht dasselbe wie das einfache/schnelle Markieren eines Rückkehrpunkts und sich nicht um die darin enthaltenen Besonderheiten zu kümmern.

@ianlancetaylor

Wenn ich ein Stoppschild sehe, erkenne ich es eher an Form und Farbe als daran, das darauf gedruckte Wort zu lesen und über seine tieferen Implikationen nachzudenken.

Meine Augen mögen über if err != nil { return err } werden, aber gleichzeitig registriert es sich immer noch – klar und sofort.

Was ich an der try -Statement-Variante mag, ist, dass sie die Boilerplate reduziert, aber auf eine Weise, die sowohl leicht zu übersehen als auch schwer zu übersehen ist.

Es kann hier oder da eine zusätzliche Zeile bedeuten, aber das sind immer noch weniger Zeilen als der Status quo.

@brynbellomy

1. Wie bieten Sie Funktionen an, die mehrere Werte zurückgeben, wie:
   func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) (Hash, Fehler) {
2. Wie würden Sie die richtige Zeile verfolgen, die den Fehler zurückgegeben hat?
3. Wenn ich das Bereichsproblem verwerfe (das auf andere Weise gelöst werden kann), bin ich mir nicht sicher

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {

    if headRef, err := r.Head(); err != nil {
        return err
    } else if parentObjOne, err := headRef.Peel(git.ObjectCommit); err != nil {
        return err
    } else parentObjTwo, err := remoteBranch.Reference.Peel(git.ObjectCommit); err != nil {
        return err
    } ...

ist in Bezug auf die Lesbarkeit nicht so unterschiedlich, aber (oder fmt.Errorf("Fehler beim Abrufen des Kopfes: %s", err.Error() ) ermöglicht es Ihnen, zusätzliche Daten einfach zu ändern und anzugeben.

Was noch nörgelt ist das

1. nachprüfen müssen ; ähm != null
2. Zurückgeben des Fehlers wie er ist, wenn wir die zusätzlichen Informationen nicht geben möchten - was in einigen Fällen keine gute Praxis ist, da Sie von der aufgerufenen Funktion abhängig sind, um einen "guten" Fehler widerzuspiegeln, der darauf hinweist, "was schief gelaufen ist ", in Fällen von file.Open , close , Remove , Db-Funktionen usw. können viele der Funktionsaufrufe denselben Fehler zurückgeben (wir können argumentieren, ob das bedeutet, dass der Entwickler, der den Fehler geschrieben hat, gute Arbeit geleistet hat oder nicht ... aber es passiert) - und dann - Sie haben einen Fehler, protokollieren Sie ihn wahrscheinlich von der Funktion, die aufgerufen hat
   "createMergeCommit", kann es aber nicht auf die genaue Zeile zurückverfolgen, in der es aufgetreten ist.

Entschuldigung, wenn jemand so etwas schon gepostet hat (es gibt viele gute Ideen :P ) Wie wäre es mit dieser alternativen Syntax:

fail := func(err error) error {
  log.Print("unexpected error", err)
  return err
}

a, b, err := f1()          // normal
c, d := f2() -> throw      // calls throw(err)
e, f := f3() -> panic      // calls panic(err)
g, h := f4() -> t.Error    // calls t.Error(err)
i, j := f5() -> fail       // calls fail(err)

das heißt, Sie haben ein -> handler rechts von einem Funktionsaufruf, der aufgerufen wird, wenn das zurückgegebene err != nil ist. Der Handler ist eine beliebige Funktion, die einen Fehler als einzelnes Argument akzeptiert und optional einen Fehler zurückgibt (dh func(error) oder func(error) error ). Wenn der Handler einen Null-Fehler zurückgibt, wird die Funktion fortgesetzt, andernfalls wird der Fehler zurückgegeben.

a := b() -> handler entspricht also:

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

Nun, als Abkürzung könnten Sie ein eingebautes try (oder ein Schlüsselwort oder einen ?= -Operator oder was auch immer) unterstützen, das für a := b() -> throw steht, sodass Sie so etwas schreiben könnten:

func() error {
  a, b := try(f1())
  c, d := try(f2())
  e, f := try(f3())
  ...
  return nil
}() -> panic // or throw/fail/whatever

Persönlich finde ich einen ?= -Operator einfacher zu lesen als ein Try-Keyword/Builtin:

func() error {
  a, b ?= f1()
  c, d ?= f2()
  e, f ?= f3()
  ...
  return nil
}() -> panic

Hinweis : Hier verwende ich throw als Platzhalter für eine eingebaute Funktion, die den Fehler an den Aufrufer zurückgibt.

Ich habe die Vorschläge zur Fehlerbehandlung bisher nicht kommentiert, weil ich im Allgemeinen dafür bin und mir gefällt, wie sie in diese Richtung gehen. Sowohl die im Vorschlag definierte try-Funktion als auch die von @thepudds vorgeschlagene try-Anweisung scheinen sinnvolle Ergänzungen der Sprache zu sein. Ich bin zuversichtlich, dass alles, was dem Go-Team einfällt, gut sein wird.

Ich möchte etwas ansprechen, das ich als geringfügiges Problem mit der Art und Weise betrachte, wie try im Vorschlag definiert ist und wie es sich auf zukünftige Erweiterungen auswirken könnte.

Try ist als eine Funktion definiert, die eine variable Anzahl von Argumenten akzeptiert.

func try(t1 T1, t2 T2, … tn Tn, te error) (T1, T2, … Tn)

Das Übergeben des Ergebnisses eines Funktionsaufrufs an try wie in try(f()) funktioniert implizit aufgrund der Art und Weise, wie mehrere Rückgabewerte in Go funktionieren.

Nach meiner Lektüre des Vorschlags sind die folgenden Ausschnitte sowohl gültig als auch semantisch äquivalent.

a, b = try(f())
//
u, v, err := f()
a, b = try(u, v, err)

Der Vorschlag wirft auch die Möglichkeit auf, try mit zusätzlichen Argumenten zu erweitern.

Wenn wir später feststellen, dass es eine gute Idee ist, eine explizit bereitgestellte Fehlerbehandlungsfunktion oder einen anderen zusätzlichen Parameter für diese Angelegenheit zu haben, ist es trivial möglich, dieses zusätzliche Argument an einen try-Aufruf zu übergeben.

Angenommen, wir möchten ein Handler-Argument hinzufügen. Es kann entweder am Anfang oder am Ende der Argumentliste stehen.

var h handler
a, b = try(h, f())
// or
a, b = try(f(), h)

Es an den Anfang zu stellen, funktioniert nicht, weil (angesichts der obigen Semantik) try nicht in der Lage wäre, zwischen einem expliziten Handler-Argument und einer Funktion zu unterscheiden, die einen Handler zurückgibt.

func f() (handler, error) { ... }
func g() (error) { ... }
try(f())
try(h, g())

Es ans Ende zu setzen, würde wahrscheinlich funktionieren, aber dann wäre try einzigartig in der Sprache, da es die einzige Funktion mit einem varargs-Parameter am Anfang der Argumentliste wäre.

Keines dieser Probleme ist ein Showstopper, aber sie lassen try unvereinbar mit dem Rest der Sprache erscheinen, und daher bin ich mir nicht sicher, ob try in Zukunft so einfach zu erweitern wäre Vorschlag Staaten.

@magisch

Einen Handler zu haben ist vielleicht mächtig:
Ich habe Sie bereits h erklärt,

du kannst

var h handler
a, b, h = f()

oder

a, b, h.err = f()

wenn es eine Funktion ist:

h:= handler(err error){
 log(...)
 return ....
} 

Dann gab es einen Vorschlag dazu

a, b, h(err) = f()

Alle können den Handler aufrufen
Und Sie können auch einen Handler "auswählen", der den Fehler zurückgibt oder nur erfasst (Fortfahren/Unterbrechen/Rückkehr), wie einige vorgeschlagen haben.

Und damit ist das Varargs-Problem weg.

Eine Alternative zu else Vorschlag von @brynbellomy:

a, b := try f() else err { /* handle error */ }

könnte sein, eine Dekorationsfunktion unmittelbar nach dem anderen zu unterstützen:

decorate := func(err error) error { return fmt.Errorf("foo failed: %v", err) }

try a, b := f() else decorate
try c, d := g() else decorate

Und vielleicht auch einige Hilfsfunktionen in der Art von:

decorate := fmt.DecorateErrorf("foo failed")

Die Dekorationsfunktion könnte die Signatur func(error) error haben und bei Vorhandensein eines Fehlers von try aufgerufen werden, kurz bevor try von der zugeordneten Funktion, die gerade versucht wird, zurückkehrt.

Das wäre im Geiste einer der früheren „Design-Iterationen“ aus dem Vorschlagsdokument ähnlich:

f := try(os.Open(filename), handler)              // handler will be called in error case

Wenn jemand etwas Komplexeres oder einen Block von Anweisungen haben möchte, könnte er stattdessen if verwenden (so wie er es heute kann).

Allerdings hat die visuelle Ausrichtung von try im Beispiel von @brynbellomy in https://github.com/golang/go/issues/32437#issuecomment -500949780 etwas Schönes.

All dies könnte immer noch mit defer funktionieren, wenn dieser Ansatz für eine einheitliche Fehlerdekoration gewählt wird (oder es könnte sogar theoretisch eine alternative Form der Registrierung einer Dekorationsfunktion geben, aber das ist ein separater Punkt).

Auf jeden Fall bin ich mir nicht sicher, was hier am besten ist, wollte aber eine andere Option explizit machen.

Hier ist das Beispiel von @brynbellomy , das mit der Funktion try neu geschrieben wurde und einen Block var verwendet, um die schöne Ausrichtung beizubehalten, auf die @thepudds in https://github.com/golang/go/issues hingewiesen hat

package main

import (
    "fmt"
    "time"
)

func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) error {
    var (
        headRef          = try(r.Head())
        parentObjOne     = try(headRef.Peel(git.ObjectCommit))
        parentObjTwo     = try(remoteBranch.Reference.Peel(git.ObjectCommit))
        parentCommitOne  = try(parentObjOne.AsCommit())
        parentCommitTwo  = try(parentObjTwo.AsCommit())
        treeOid          = try(index.WriteTree())
        tree             = try(r.LookupTree(treeOid))
        remoteBranchName = try(remoteBranch.Name())
    )

    userName, userEmail, err := r.UserIdentityFromConfig()
    if err != nil {
        userName = ""
        userEmail = ""
    }

    var (
        now       = time.Now()
        author    = &git.Signature{Name: userName, Email: userEmail, When: now}
        committer = &git.Signature{Name: userName, Email: userEmail, When: now}
        message   = fmt.Sprintf(`Merge branch '%v' of %v`, remoteBranchName, remote.Url())
        parents   = []*git.Commit{
            parentCommitOne,
            parentCommitTwo,
        }
    )

    _, err = r.CreateCommit(headRef.Name(), author, committer, message, tree, parents...)
    return err
}

Es ist so prägnant wie die try -Anweisungsversion, und ich würde argumentieren, dass es genauso lesbar ist. Da try ein Ausdruck ist, könnten einige dieser Zwischenvariablen auf Kosten der Lesbarkeit eliminiert werden, aber das scheint eher eine Frage des Stils als alles andere zu sein.

Es wirft jedoch die Frage auf, wie try in einem var -Block funktioniert. Ich gehe davon aus, dass jede Zeile der var als separate Anweisung zählt und nicht der gesamte Block eine einzelne Anweisung ist, was die Reihenfolge betrifft, was wann zugewiesen wird.

Es wäre gut, wenn der "try"-Vorschlag explizit die Konsequenzen für Tools wie cmd/cover nennen würde, die Testabdeckungsstatistiken mit naiver Anweisungszählung annähern. Ich mache mir Sorgen, dass der unsichtbare Fehlerkontrollfluss zu einer Unterzählung führen könnte.

@thepudds

versuche a, b := f() sonst dekoriere

Vielleicht ist es ein zu tiefes Brennen in meinen Gehirnzellen, aber das trifft mich zu sehr

try a, b := f() ;catch(decorate)

und ein rutschiger Abhang zu a

a, b := f()
catch(decorate)

Ich denke, Sie können sehen, wohin das führt, und für mich vergleichen

    try headRef := r.Head()
    try parentObjOne := headRef.Peel(git.ObjectCommit)
    try parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    try parentCommitOne := parentObjOne.AsCommit()
    try parentCommitTwo := parentObjTwo.AsCommit()
    try treeOid := index.WriteTree()
    try tree := r.LookupTree(treeOid)
    try remoteBranchName := remoteBranch.Name()

mit

    try ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    )

(oder sogar ein Haken am Ende)
Die zweite ist besser lesbar, betont aber die Tatsache, dass die folgenden Funktionen 2 Variablen zurückgeben, und wir verwerfen auf magische Weise eine und sammeln sie in einem "magisch zurückgegebenen Fehler" .

    try(err) ( 
    headRef := r.Head()
    parentObjOne := headRef.Peel(git.ObjectCommit)
    parentObjTwo := remoteBranch.Reference.Peel(git.ObjectCommit)
    parentCommitOne := parentObjOne.AsCommit()
    parentCommitTwo := parentObjTwo.AsCommit()
    treeOid := index.WriteTree()
    tree := r.LookupTree(treeOid)
    remoteBranchName := remoteBranch.Name()
    ); err!=nil {
      //handle the err
    }

setzt zumindest die zurückzugebende Variable explizit und lässt mich sie innerhalb der Funktion handhaben, wann immer ich will.

Ich werfe nur einen bestimmten Kommentar ein, da ich niemanden explizit gesehen habe, der ihn ausdrücklich erwähnt hat, insbesondere über die Änderung gofmt , um die folgende einzeilige Formatierung oder eine beliebige Variante zu unterstützen:

if f() { return nil, err }

Bitte nicht. Wenn wir eine einzelne Zeile if wollen, dann machen Sie bitte eine einzelne Zeile if , z.

if f() then return nil, err

Aber bitte, bitte, bitte nehmen Sie keinen Syntaxsalat an, indem Sie die Zeilenumbrüche entfernen, die es einfacher machen, Code zu lesen, der geschweifte Klammern verwendet.

Ich möchte ein paar Dinge hervorheben, die in der Hitze der Diskussion vielleicht vergessen wurden:

1) Der ganze Sinn dieses Vorschlags besteht darin, die allgemeine Fehlerbehandlung in den Hintergrund treten zu lassen - die Fehlerbehandlung sollte den Code nicht dominieren. Sollte aber trotzdem explizit sein. Alle alternativen Vorschläge, die die Fehlerbehandlung noch mehr herausragen lassen, gehen am Ziel vorbei. Wie @ianlancetaylor bereits sagte, wenn diese alternativen Vorschläge die Menge an Textbausteinen nicht wesentlich reduzieren, können wir einfach bei den if -Anweisungen bleiben. (Und die Bitte, Boilerplate zu reduzieren, kommt von Ihnen, der Go-Community.)

2) Eine der Beschwerden über den aktuellen Vorschlag ist die Notwendigkeit, das Fehlerergebnis zu benennen, um darauf zugreifen zu können. Jeder Alternativvorschlag wird das gleiche Problem haben, es sei denn, die Alternative führt eine zusätzliche Syntax ein, dh mehr Textbausteine ​​(wie etwa ... else err { ... } und dergleichen), um diese Variable explizit zu benennen. Aber was interessant ist: Wenn wir uns nicht darum kümmern, einen Fehler zu dekorieren und die Ergebnisparameter nicht zu benennen, aber trotzdem ein explizites return benötigen, weil es eine Art expliziten Handler gibt, diese return -Anweisung müssen alle (normalerweise null) Ergebniswerte aufzählen, da eine nackte Rückgabe in diesem Fall nicht zulässig ist. Besonders wenn eine Funktion viele Fehler zurückgibt, ohne den Fehler zu schmücken, fügen diese expliziten Rückgaben ( return nil, err usw.) der Boilerplate hinzu. Der aktuelle Vorschlag und jede Alternative, die kein explizites return erfordert, beseitigt dies. Andererseits, wenn man den Fehler schmücken will, _erfordert_ der aktuelle Vorschlag, dass man das Fehlerergebnis (und damit alle anderen Ergebnisse) benennt, um Zugriff auf den Fehlerwert zu bekommen. Das hat den netten Nebeneffekt, dass man in einem expliziten Handler eine nackte Rückgabe verwenden kann und nicht alle anderen Ergebniswerte wiederholen muss. (Ich weiß, dass nackte Renditen einige starke Gefühle haben, aber die Realität ist, dass es ein echtes Ärgernis ist, alle anderen (normalerweise null) Ergebniswerte aufzählen zu müssen, wenn wir uns nur um das Fehlerergebnis kümmern - es fügt dem nichts hinzu Verständnis des Codes). Mit anderen Worten, das Fehlerergebnis so benennen zu müssen, dass es dekoriert werden kann, ermöglicht eine weitere Reduzierung der Boilerplate.

@magical Danke für den Hinweis . Das Gleiche ist mir kurz nach dem Posten des Vorschlags aufgefallen (aber nicht zur Sprache gebracht, um keine weitere Verwirrung zu stiften). Sie haben Recht, dass try so wie es ist nicht verlängert werden konnte. Glücklicherweise ist die Lösung einfach genug. (Zufälligerweise hatten unsere früheren internen Vorschläge dieses Problem nicht - es wurde eingeführt, als ich unsere endgültige Version für die Veröffentlichung neu schrieb und versuchte, try zu vereinfachen, um den bestehenden Parameterübergaberegeln besser zu entsprechen. Es schien wie eine nette - aber wie sich herausstellt, fehlerhaft und größtenteils nutzlos - profitieren Sie davon, try(a, b, c, handle) schreiben zu können.)

Eine frühere Version von try definierte es ungefähr wie folgt: try(expr, handler) nimmt einen (oder vielleicht zwei) Ausdruck als Argument, wobei der erste Ausdruck mehrwertig sein kann (kann nur passieren, wenn der Ausdruck ist ein Funktionsaufruf). Der letzte Wert dieses (möglicherweise mehrwertigen) Ausdrucks muss vom Typ error sein, und dieser Wert wird gegen nil getestet. (etc. - den Rest können Sie sich vorstellen).

Wie auch immer, der Punkt ist, dass try syntaktisch nur einen oder vielleicht zwei Ausdrücke akzeptiert. (Aber es ist etwas schwieriger, die Semantik von try zu beschreiben.) Die Konsequenz wäre dieser Code wie:

a, b := try(u, v, err)

wäre nicht mehr erlaubt. Aber es gibt wenig Grund dafür, dass dies überhaupt funktioniert: In den meisten Fällen (es sei denn, a und b sind benannte Ergebnisse) könnte dieser Code - falls er aus irgendeinem Grund wichtig ist - leicht umgeschrieben werden

a, b := u, v  // we don't care if the assignment happens in case of an error
try(err)

(oder verwenden Sie bei Bedarf eine if -Anweisung). Aber auch das scheint unwichtig zu sein.

diese return-Anweisung muss alle (normalerweise null) Ergebniswerte aufzählen, da eine nackte Rückgabe in diesem Fall nicht zulässig ist

Eine nackte Rückkehr ist nicht erlaubt, aber ein Versuch wäre es. Eine Sache, die ich an try (entweder als Funktion oder als Anweisung) mag, ist, dass ich nicht mehr darüber nachdenken muss, wie man fehlerfreie Werte setzt, wenn ein Fehler zurückgegeben wird, ich werde einfach try verwenden.

@griesemer Danke für die Erklärung. Zu dem Schluss bin ich auch gekommen.

Ein kurzer Kommentar zu try als Statement: Wie ich denke, ist im Beispiel in https://github.com/golang/go/issues/32437#issuecomment -501035322 zu sehen, das try begräbt die Lede. Code wird zu einer Reihe von try -Anweisungen, die verschleiern, was der Code tatsächlich tut.

Vorhandener Code kann eine neu deklarierte Fehlervariable nach dem Block if err != nil wiederverwenden. Das Ausblenden der Variablen würde das brechen, und das Hinzufügen einer benannten Rückgabevariablen zur Funktionssignatur wird es nicht immer beheben.

Vielleicht ist es am besten, die Fehlerdeklaration/-zuweisung so zu lassen, wie sie ist, und eine einzeilige Fehlerbehandlungs-stmt zu finden.

err := f() // followed by one of

on err, return err            // any type can be tested for non-zero
on err, return fmt.Errorf(...)
on err, fmt.Println(err)      // doesn't stop the function
on err, hname err             // handler invocation without parens
on err, ignore err            // optional ignore handler logs error if defined

if err, return err            // alternatively, use if

handle hname(err error, clr caller) { // type caller has results of runtime.Caller()
   if err == io.Bad { return err }
   fmt.Println(clr.name, err)
}

Ein Unterausdruck try könnte panisch werden, was bedeutet, dass niemals ein Fehler erwartet wird. Eine Variante davon könnte jeden Fehler ignorieren.

f(try g()) // panic on error
f(try_ g()) // ignore any error

Der ganze Sinn dieses Vorschlags besteht darin, die allgemeine Fehlerbehandlung in den Hintergrund treten zu lassen – die Fehlerbehandlung sollte den Code nicht dominieren. Sollte aber trotzdem explizit sein.

Ich mag die Idee, dass die Kommentare try als Aussage auflisten. Es ist explizit, immer noch leicht zu beschönigen (da es eine feste Länge hat), aber nicht _so_ leicht zu beschönigen (da es immer an der gleichen Stelle ist), dass sie in einer überfüllten Zeile versteckt werden können. Es kann auch wie zuvor erwähnt mit defer fmt.HandleErrorf(...) kombiniert werden, hat jedoch die Gefahr, benannte Parameter zu missbrauchen, um Fehler zu umschließen (was mir immer noch wie ein cleverer Hack erscheint. Clevere Hacks sind schlecht.)

Einer der Gründe, warum ich try als Ausdruck nicht mochte, ist, dass es entweder zu leicht zu beschönigen ist oder nicht leicht genug, um es zu beschönigen. Nehmen Sie die folgenden zwei Beispiele:

Versuchen Sie es als Ausdruck

// Too hidden, it's in a crowded function with many symbols that complicate the function.

f, err := os.OpenFile(try(FileName()), os.O_APPEND|os.O_WRONLY, 0600)

// Not easy enough, the word "try" already increases horizontal complexity, and it
// being an expression only encourages more horizontal complexity.
// If this code weren't collapsed to multiple lines, it would be extremely
// hard to read and unclear as to what's executing when.

fullContents := try(io.CopyN(
    os.Stdout,
    try(net.Dial("tcp", "localhost:"+try(buf.ReadString("\n"))),
    try(strconv.Atoi(try(buf.ReadString("\n")))),
))

Versuchen Sie es als Aussage

// easy to see while still not being too verbose

try name := FileName()
os.OpenFile(name, os.O_APPEND|os.O_WRONLY, 0600)

// does not allow for clever one-liners, code remains much more readable.
// also, the code reads in sequence from top-to-bottom.

try port := r.ReadString("\n")
try lengthStr := r.ReadString("\n")
try length := strconv.Atoi(lengthStr)

try con := net.Dial("tcp", "localhost:"+port)
try io.CopyN(os.Stdout, con, length)

Imbiss

Dieser Code ist definitiv erfunden, das gebe ich zu. Aber worauf ich hinaus will ist, dass try im Allgemeinen als Ausdruck nicht gut funktioniert in:

1. Die Mitte von überfüllten Ausdrücken, die nicht viel Fehlerprüfung erfordern
2. Relativ einfache mehrzeilige Anweisungen, die viel Fehlerprüfung erfordern

Ich stimme jedoch @ianlancetaylor zu, dass der Anfang jeder Zeile mit try dem wichtigen Teil jeder Anweisung (der definierten Variablen oder der ausgeführten Funktion) im Wege zu stehen scheint. Ich denke jedoch, weil es sich an derselben Stelle befindet und eine feste Breite hat, ist es viel einfacher, es zu beschönigen, während es immer noch bemerkt wird. Allerdings sind die Augen jedes Menschen anders.

Ich denke auch, dass die Förderung cleverer Einzeiler im Code im Allgemeinen nur eine schlechte Idee ist. Ich bin überrascht, dass ich einen so mächtigen Einzeiler wie in meinem ersten Beispiel erstellen konnte, es ist ein Ausschnitt, der seine eigene vollständige Funktion verdient, weil er so viel leistet – aber er passt in eine Zeile, wenn ich ihn nicht reduziert hätte um der Lesbarkeit willen zu vervielfachen. Alles in einer Zeile:

fullContents := try(io.CopyN(os.Stdout, try(net.Dial("tcp", "localhost:"+try(r.ReadString("\n"))), try(strconv.Atoi(try(r.ReadString("\n"))))))

Es liest einen Port aus einem *bufio.Reader , startet eine TCP-Verbindung und kopiert eine Anzahl von Bytes, die von demselben *bufio.Reader angegeben werden, nach stdout . Alles mit Fehlerbehandlung. Für eine Sprache mit so strengen Codierungskonventionen denke ich nicht, dass dies überhaupt erlaubt sein sollte. Ich denke, gofmt könnte dabei helfen.

Für eine Sprache mit so strengen Codierungskonventionen denke ich nicht, dass dies überhaupt erlaubt sein sollte.

Es ist möglich, abscheulichen Code in Go zu schreiben. Es ist sogar möglich, es schrecklich zu formatieren; es gibt nur starke Normen und Werkzeuge dagegen. Go hat sogar goto .

Bei Codeüberprüfungen bitte ich die Leute manchmal, komplizierte Ausdrücke in mehrere Anweisungen mit nützlichen Zwischennamen aufzuteilen. Ich würde aus dem gleichen Grund etwas Ähnliches für tief verschachtelte try s machen.

Das ist alles, um zu sagen: Lassen Sie uns nicht zu sehr versuchen, schlechten Code auf Kosten der Sprachverzerrung zu verbieten. Wir haben andere Mechanismen, um Code sauber zu halten, die besser für etwas geeignet sind, das im Wesentlichen menschliches Urteilsvermögen von Fall zu Fall erfordert.

Es ist möglich, abscheulichen Code in Go zu schreiben. Es ist sogar möglich, es schrecklich zu formatieren; es gibt nur starke Normen und Werkzeuge dagegen. Go hat sogar goto.

Bei Codeüberprüfungen bitte ich die Leute manchmal, komplizierte Ausdrücke in mehrere Anweisungen mit nützlichen Zwischennamen aufzuteilen. Ich würde aus dem gleichen Grund etwas Ähnliches für tief verschachtelte Versuche tun.

Das ist alles, um zu sagen: Lassen Sie uns nicht zu sehr versuchen, schlechten Code auf Kosten der Sprachverzerrung zu verbieten. Wir haben andere Mechanismen, um Code sauber zu halten, die besser für etwas geeignet sind, das im Wesentlichen menschliches Urteilsvermögen von Fall zu Fall erfordert.