Je suis d'accord que c'est la meilleure voie à suivre : résoudre le problème le plus courant avec une conception simple.

Je ne veux pas faire de bikeshed (n'hésitez pas à reporter cette conversation), mais Rust y est allé et s'est finalement installé avec l'opérateur postfix ? plutôt qu'une fonction intégrée, pour une lisibilité accrue.

La proposition de gophercon cite ? dans les idées envisagées et donne trois raisons pour lesquelles elle a été rejetée : la première (« les transferts de flux de contrôle sont en règle générale accompagnés de mots-clés ») et la troisième (« les gestionnaires sont plus naturellement définis avec un mot-clé, donc les chèques aussi") ne s'appliquent plus. Le second est stylistique : il dit que, même si l'opérateur postfix fonctionne mieux pour le chaînage, il peut encore lire moins bien dans certains cas comme :

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

plutôt que:

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

mais maintenant on aurait :

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

ce qui, je pense, est clairement le pire des trois, car il n'est même plus évident de savoir quelle est la fonction principale appelée.

Donc, l'essentiel de mon commentaire est que les trois raisons citées dans la proposition gophercon pour ne pas utiliser ? ne s'appliquent pas à cette proposition try ; ? est concis, très lisible, il n'obscurcit pas la structure de l'instruction (avec sa hiérarchie d'appel de fonction interne) et il est chaîné. Il supprime encore plus l'encombrement de la vue, sans obscurcir le flux de contrôle plus que le try() proposé ne le fait déjà.

Clarifier:

Fait

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

retourner (0, "x") ou (7, "x") ? Je suppose que ce dernier.

Le retour d'erreur doit-il être nommé dans le cas où il n'y a pas de décoration ou de gestion (comme dans une fonction d'assistance interne) ? Je suppose que non.

Votre exemple renvoie 7, errors.New("x") . Cela devrait être clair dans le document complet qui sera bientôt soumis (https://golang.org/cl/180557).

Le paramètre de résultat d'erreur n'a pas besoin d'être nommé pour utiliser try . Il n'a besoin d'être nommé que si la fonction doit y faire référence dans une fonction différée ou ailleurs.

Je suis vraiment mécontent d'une _fonction_ intégrée affectant le flux de contrôle de l'appelant. J'apprécie l'impossibilité d'ajouter de nouveaux mots-clés dans Go 1, mais contourner ce problème avec des fonctions intégrées magiques me semble tout simplement faux. L'observation d'autres éléments intégrés n'a pas de résultats aussi imprévisibles que le changement de flux de contrôle.

Je n'aime pas l'apparence de postfix ? , mais je pense qu'il bat toujours try() .

Edit : Eh bien, j'ai réussi à oublier complètement que la panique existe et n'est pas un mot-clé.

La proposition détaillée est maintenant ici (en attendant des améliorations de formatage, à venir sous peu) et, espérons-le, répondra à beaucoup de questions.

@dominikh La proposition détaillée en discute longuement, mais veuillez noter que panic et recover sont deux éléments intégrés qui affectent également le flux de contrôle.

Une précision/suggestion d'amélioration :

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

Cela pourrait-il plutôt dire is set to that non-nil error value and the enclosing function returns ? (s/avant/et)

Lors de la première lecture, before the enclosing function returns semblait définir _éventuellement_ la valeur d'erreur à un moment donné dans le futur juste avant le retour de la fonction - éventuellement dans une ligne ultérieure. L'interprétation correcte est que try peut provoquer le retour de la fonction en cours. C'est un comportement surprenant pour le langage actuel, donc un texte plus clair serait le bienvenu.

Je pense que ce n'est que du sucre, et un petit nombre d'opposants vocaux ont taquiné Golang à propos de l'utilisation répétée de taper if err != nil ... et quelqu'un l'a pris au sérieux. Je ne pense pas que ce soit un problème. Les seules choses manquantes sont ces deux éléments intégrés :

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

Je ne sais pas pourquoi quelqu'un écrirait jamais une fonction comme celle-ci, mais quelle serait la sortie envisagée pour

try(foobar())

Si foobar renvoyé (error, error)

Je retire mes préoccupations précédentes concernant le flux de contrôle et je ne suggère plus d'utiliser ? . Je m'excuse pour la réponse instinctive (même si je tiens à souligner que cela ne se serait pas produit si le problème avait été signalé _après_ que la proposition complète était disponible).

Je ne suis pas d'accord avec la nécessité d'une gestion simplifiée des erreurs, mais je suis sûr que c'est une bataille perdue d'avance. try comme indiqué dans la proposition semble être la moins mauvaise façon de le faire.

@webermaster Seul le dernier résultat error est spécial pour l'expression passée à try , comme décrit dans le document de proposition.

Comme @dominikh , je suis également en désaccord avec la nécessité d'une gestion simplifiée des erreurs.

Il transforme la complexité verticale en complexité horizontale, ce qui est rarement une bonne idée.

Si je devais absolument choisir entre simplifier les propositions de gestion des erreurs, ce serait ma proposition préférée.

Il serait utile que cela puisse être accompagné (à un certain stade d'acceptation) d'un outil pour transformer le code Go afin d'utiliser try dans un sous-ensemble de fonctions renvoyant des erreurs où une telle transformation peut être facilement effectuée sans changer de sémantique. Trois avantages me viennent à l'esprit :

• Lors de l'évaluation de cette proposition, cela permettrait aux gens d'avoir rapidement une idée de la façon dont try pourrait être utilisé dans leur base de code.
• Si try atterrit dans une future version de Go, les gens voudront probablement changer leur code pour l'utiliser. Avoir un outil pour automatiser les cas faciles aidera beaucoup.
• Avoir un moyen de transformer rapidement une grande base de code pour utiliser try facilitera l'examen des effets de la mise en œuvre à grande échelle. (Correctivité, performances et taille de code, par exemple.) L'implémentation peut être suffisamment simple pour en faire une considération négligeable, cependant.

Je voudrais juste exprimer que je pense qu'un seul try(foo()) renflouant réellement la fonction d'appel nous enlève le signal visuel que le flux de fonction peut changer en fonction du résultat.

Je sens que je peux travailler avec try étant donné qu'il est suffisamment utilisé, mais je pense aussi que nous aurons besoin d'un support IDE supplémentaire (ou d'un autre) pour mettre en évidence try afin de reconnaître efficacement le flux implicite dans les révisions de code /sessions de débogage

La chose qui me préoccupe le plus est la nécessité d'avoir des valeurs de retour nommées juste pour que l'instruction de report soit heureuse.

Je pense que le problème global de gestion des erreurs dont la communauté se plaint est une combinaison du passe-partout de if err != nil ET de l'ajout de contexte aux erreurs. La FAQ indique clairement que ce dernier est intentionnellement laissé de côté en tant que problème distinct, mais j'ai l'impression que cela devient alors une solution incomplète, mais je serai prêt à lui donner une chance après avoir réfléchi à ces 2 choses :

1. Déclarez err au début de la fonction.
   Est-ce que ça marche? Je me souviens de problèmes avec des résultats différés et sans nom. Si ce n'est pas le cas, la proposition doit en tenir compte.

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

1. Attribuez des valeurs comme nous l'avons fait dans le passé, mais utilisez une fonction d'assistance wrapf qui a le passe- if err != nil .

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
}

Si l'un ou l'autre fonctionne, je peux m'en occuper.

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

Cela ne fonctionnera pas. Le report mettra à jour la variable locale err , qui n'est pas liée à la valeur de retour.

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
}

Cela devrait fonctionner. Cependant, il appellera wrapf même sur une erreur nulle.
Cela fonctionnera également (continuera à) fonctionner, et est beaucoup plus clair à l'OMI :

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

Personne ne vous fera utiliser try .

Je ne sais pas pourquoi quelqu'un écrirait jamais une fonction comme celle-ci, mais quelle serait la sortie envisagée pour

try(foobar())

Si foobar renvoyé (error, error)

Pourquoi renverriez-vous plus d'une erreur à partir d'une fonction ? Si vous renvoyez plus d'une erreur de la fonction, peut-être que la fonction devrait être divisée en deux en premier lieu, chacune ne renvoyant qu'une seule erreur.

Pourriez-vous développer avec un exemple?

@cespare : Il devrait être possible pour quelqu'un d'écrire un go fix qui réécrit le code existant adapté à try sorte qu'il utilise try . Il peut être utile d'avoir une idée de la façon dont le code existant pourrait être simplifié. Nous ne nous attendons pas à des changements significatifs dans la taille ou les performances du code, car try n'est qu'un sucre syntaxique, remplaçant un modèle commun par un morceau de code source plus court qui produit essentiellement le même code de sortie. Notez également que le code qui utilise try sera obligé d'utiliser une version Go qui est au moins la version à laquelle try a été introduit.

@lestrrat : Convenu qu'il faudra apprendre que try peut changer le flux de contrôle. Nous soupçonnons que les IDE pourraient le mettre en évidence assez facilement.

@Goodwine : Comme @randall77 l' a déjà souligné, votre première suggestion ne fonctionnera pas. Une option à laquelle nous avons pensé (mais non discutée dans la doc) est la possibilité d'avoir une variable prédéclarée qui indique le résultat error (s'il y en a une en premier lieu). Cela éliminerait le besoin de nommer ce résultat juste pour qu'il puisse être utilisé dans un defer . Mais ce serait encore plus magique ; cela ne semble pas justifié. Le problème avec la dénomination du résultat de retour est essentiellement cosmétique, et là où cela compte le plus, c'est dans les API générées automatiquement servies par go doc et ses amis. Il serait facile d'aborder cela dans ces outils (voir aussi la FAQ détaillée de la doc de conception à ce sujet).

@nictuku : Concernant votre suggestion de clarification (s/before/and/) : je pense que le code juste avant le paragraphe auquel vous faites référence indique clairement ce qui se passe exactement, mais je vois votre point, s/before/and/ may rendre la prose plus claire. Je vais faire le changement.

Voir CL 180637 .

J'aime vraiment beaucoup cette proposition. Cependant, j'ai une critique. Le point de sortie des fonctions dans Go a toujours été marqué par un return . Les paniques sont également des points de sortie, mais ce sont des erreurs catastrophiques qui ne sont généralement pas censées être rencontrées.

Faire un point de sortie d'une fonction qui n'est pas un return , et qui est censé être banal, peut conduire à un code beaucoup moins lisible. J'en avais entendu parler lors d'une conférence et il est difficile de ne pas voir la beauté de la structure de ce code :

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)
    }
}

Ce code peut ressembler à un gros gâchis, et était _signifié_ par le brouillon de gestion des erreurs, mais comparons-le à la même chose avec 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
}

Vous pouvez regarder cela à première vue et penser que cela semble mieux, car il y a beaucoup moins de code répété. Cependant, il était très facile de repérer tous les points renvoyés par la fonction dans le premier exemple. Ils étaient tous en retrait et commençaient par return , suivi d'un espace. Cela est dû au fait que tous les retours conditionnels _doivent_ être à l'intérieur de blocs conditionnels, étant ainsi indentés par les normes gofmt . return est aussi, comme indiqué précédemment, le seul moyen de quitter une fonction sans dire qu'une erreur catastrophique s'est produite. Dans le deuxième exemple, il n'y a qu'un seul return , il semble donc que la seule chose que la fonction _ever_ devrait retourner soit nil . Les deux derniers appels try sont faciles à voir, mais les deux premiers sont un peu plus difficiles, et le seraient encore plus s'ils étaient imbriqués quelque part, c'est-à-dire quelque chose comme proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) .

Revenir d'une fonction semble avoir été une chose "sacrée" à faire, c'est pourquoi je pense personnellement que tous les points de sortie d'une fonction devraient être marqués par return .

Quelqu'un l'a déjà mis en place il y a 5 ans. Si vous êtes intéressé, vous pouvez
essayez cette fonctionnalité

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

J'ai implémenté try() dans Go il y a cinq ans avec un préprocesseur AST et je l'ai utilisé dans de vrais projets, c'était plutôt sympa : https://github.com/lunixbochs/og

Voici quelques exemples de mon utilisation dans les fonctions error-check-heavy : https://github.com/lunixbochs/poxd/blob/master/tls.go#L13

J'apprécie l'effort qui a été fait. Je pense que c'est la solution la plus efficace que j'ai vue jusqu'à présent. Mais je pense que cela introduit un tas de travail lors du débogage. Déballer essayer et ajouter un bloc if chaque fois que je débogue et le réemballer quand j'ai fini est fastidieux. Et j'ai aussi quelques grincer des dents à propos de la variable d'erreur magique que je dois prendre en compte. Je n'ai jamais été dérangé par la vérification explicite des erreurs, alors je suis peut-être la mauvaise personne à qui demander. Il m'a toujours semblé "prêt à déboguer".

@griesemer
Mon problème avec votre utilisation proposée de différer comme moyen de gérer l'emballage d'erreur est que le comportement de l'extrait que j'ai montré (répété ci-dessous) n'est pas très courant AFAICT, et parce que c'est très rare, je peux imaginer que les gens écrivent ceci en pensant que cela fonctionne quand ce n'est pas le cas.

Comme .. un débutant ne le saurait pas, s'il a un bogue à cause de cela, il n'ira pas "bien sûr, j'ai besoin d'un retour nommé", il serait stressé parce que ça devrait marcher et ça ne marche pas.

var err error
defer fmt.HandleErrorf(err);

try est déjà trop magique, vous pouvez donc aller jusqu'au bout et ajouter cette valeur d'erreur implicite. Pensez aux débutants, pas à ceux qui connaissent toutes les nuances du Go. Si ce n'est pas assez clair, je ne pense pas que ce soit la bonne solution.

Ou... Ne suggérez pas d'utiliser un report comme celui-ci, essayez une autre méthode plus sûre mais toujours lisible.

@deanveloper Il est vrai que cette proposition (et d'ailleurs, toute proposition essayant de tenter la même chose) supprimera les déclarations explicitement visibles return du code source - c'est tout l'intérêt de la proposition après tout, n'est-ce pas? Pour supprimer le passe-partout des déclarations if et returns qui sont toutes identiques. Si vous voulez conserver les return , n'utilisez pas try .

Nous sommes habitués à reconnaître immédiatement les instructions return (et panic ) car c'est ainsi que ce type de flux de contrôle est exprimé en Go (et dans de nombreux autres langages). Il ne semble pas exagéré que nous reconnaissions également try comme un changement de flux de contrôle après s'y être habitué, tout comme nous le faisons pour return . Je ne doute pas qu'un bon support IDE aidera également à cela.

J'ai deux soucis :

• les retours nommés ont été très déroutants, ce qui les encourage avec un nouveau cas d'utilisation important
• cela découragera l'ajout de contexte aux erreurs

D'après mon expérience, ajouter du contexte aux erreurs immédiatement après chaque site d'appel est essentiel pour avoir un code qui peut être facilement débogué. Et les retours nommés ont semé la confusion chez presque tous les développeurs Go que je connais à un moment donné.

Une préoccupation stylistique plus mineure est qu'il est regrettable de voir combien de lignes de code seront désormais enveloppées dans try(actualThing()) . Je peux imaginer voir la plupart des lignes dans une base de code enveloppée dans try() . C'est malheureux.

Je pense que ces préoccupations seraient résolues avec un ajustement:

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

check() se comporterait un peu comme try() , mais abandonnerait le comportement de transmission générique des valeurs de retour de fonction et offrirait à la place la possibilité d'ajouter du contexte. Cela déclencherait quand même un retour.

Cela conserverait de nombreux avantages de try() :

• c'est un intégré
• il suit le flux de contrôle existant WRT pour différer
• il s'aligne sur la pratique existante consistant à bien ajouter du contexte aux erreurs
• il s'aligne sur les propositions et les bibliothèques actuelles pour l'emballage des erreurs, telles que errors.Wrap(err, "context message")
• il en résulte un site d'appel propre : il n'y a pas de passe-partout sur la ligne a, b, err := myFunc()
• décrire les erreurs avec defer fmt.HandleError(&err, "msg") est toujours possible, mais n'a pas besoin d'être encouragé.
• la signature de check est légèrement plus simple, car elle n'a pas besoin de renvoyer un nombre arbitraire d'arguments de la fonction qu'elle enveloppe.

@s4n-gt Merci pour ce lien. Je n'en étais pas conscient.

@Goodwine Point pris. La raison de ne pas fournir une prise en charge plus directe de la gestion des erreurs est expliquée en détail dans la documentation de conception. C'est aussi un fait qu'au cours d'un an environ (depuis les projets de conception publiés au Gophercon de l'année dernière), aucune solution satisfaisante pour la gestion explicite des erreurs n'a été proposée. C'est pourquoi cette proposition laisse cela exprès (et suggère à la place d'utiliser un defer ). Cette proposition laisse encore la porte ouverte à de futures améliorations à cet égard.

La proposition mentionne la modification des tests de package pour permettre aux tests et aux benchmarks de renvoyer une erreur. Bien que ce ne soit pas "un changement de bibliothèque modeste", nous pourrions également envisager d'accepter func main() error . Cela rendrait l'écriture de petits scripts beaucoup plus agréable. La sémantique serait équivalente à :

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

Une dernière critique. Pas vraiment une critique de la proposition elle-même, mais plutôt une critique d'une réponse commune au contre-argument de la "fonction contrôlant le flux".

La réponse à "Je n'aime pas qu'une fonction contrôle le flux" est que " panic contrôle également le flux du programme!". Cependant, il y a quelques raisons pour lesquelles il est plus acceptable que panic fasse cela qui ne s'applique pas à try .

1. panic est convivial pour les programmeurs débutants car ce qu'il fait est intuitif, il continue à déballer la pile. On ne devrait même pas avoir à chercher comment fonctionne panic pour comprendre ce qu'il fait. Les programmeurs débutants n'ont même pas besoin de s'inquiéter de recover , puisque les débutants ne construisent généralement pas de mécanismes de récupération de panique, d'autant plus qu'ils sont presque toujours moins favorables que d'éviter simplement la panique en premier lieu.

2. panic est un nom facile à voir. Cela apporte de l'inquiétude, et il le faut. Si quelqu'un voit panic dans une base de code, il devrait immédiatement penser à comment _éviter_ la panique, même si c'est trivial.

3. En s'appuyant sur le dernier point, panic ne peut pas être imbriqué dans un appel, ce qui le rend encore plus facile à voir.

Il n'y a rien de mal à paniquer pour contrôler le déroulement du programme car il est extrêmement facile à repérer et il est intuitif quant à ce qu'il fait.

La fonction try ne satisfait aucun de ces points.

1. On ne peut pas deviner ce que fait try sans consulter la documentation correspondante. De nombreuses langues utilisent le mot-clé de différentes manières, ce qui rend difficile de comprendre ce que cela signifierait en Go.

2. try n'attire pas mon attention, surtout lorsqu'il s'agit d'une fonction. _Surtout_ lorsque la coloration syntaxique le mettra en évidence en tant que fonction. _SPECIALLY_ après avoir développé dans un langage comme Java, où try est considéré comme un passe-partout inutile (à cause des exceptions vérifiées).

3. try peut être utilisé dans un argument d'un appel de fonction, comme dans mon exemple dans mon commentaire précédent proc := try(os.FindProcess(try(strconv.Atoi(os.Args[1])))) . Cela le rend encore plus difficile à repérer.

Mes yeux ignorent les fonctions try , même lorsque je les recherche spécifiquement. Mes yeux les verront, mais passeront immédiatement aux appels os.FindProcess ou strconv.Atoi . try est un retour conditionnel. Le flux de contrôle ET les retours sont tous deux maintenus sur des socles en Go. Tout le flux de contrôle dans une fonction est en retrait et tous les retours commencent par return . Mélanger ces deux concepts ensemble dans un appel de fonction facile à manquer semble juste un peu décalé.

Ce commentaire et mon dernier sont cependant mes seules véritables critiques à l'idée. Je pense que je n'aime peut-être pas cette proposition, mais je pense toujours que c'est une victoire globale pour Go. Cette solution ressemble toujours plus à Go que les autres solutions. Si cela était ajouté, je serais heureux, mais je pense que cela peut encore être amélioré, je ne sais pas comment.

@buchanae intéressant. Tel qu'il est écrit, cependant, il déplace le formatage de style fmt d'un paquet vers le langage lui-même, ce qui ouvre une boîte de Pandore.

Tel qu'il est écrit, cependant, il déplace le formatage de style fmt d'un paquet vers le langage lui-même, ce qui ouvre une boîte de Pandore.

Bon point. Un exemple plus simple :

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

@buchanae Nous avons envisagé de rendre la gestion des erreurs explicite plus directement liée à try - veuillez consulter la documentation de conception détaillée, en particulier la section sur les itérations de conception. Votre suggestion spécifique de check ne permettrait d'augmenter les erreurs qu'à travers quelque chose comme une API de type fmt.Errorf (dans le cadre du check ), si je comprends bien. En général, les gens peuvent vouloir faire toutes sortes de choses avec des erreurs, pas seulement en créer une nouvelle qui fait référence à l'original via sa chaîne d'erreur.

Encore une fois, cette proposition ne tente pas de résoudre toutes les situations de gestion d'erreurs. Je suppose que dans la plupart des cas, try a du sens pour un code qui ressemble maintenant à ceci :

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

Il y a énormément de code qui ressemble à ça. Et chaque morceau de code ressemblant à celui-ci n'a pas besoin de plus de gestion des erreurs. Et là où defer n'est pas correct, on peut toujours utiliser une instruction if .

Je ne suis pas cette ligne :

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

Il laisse tomber l'erreur entrante sur le sol, ce qui est inhabituel. Est-il destiné à être utilisé quelque chose de plus comme ça?

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

La duplication de err est un peu bégaiement. Ce n'est pas vraiment directement à propos de la proposition, juste un commentaire secondaire sur la doc.

Je partage les deux préoccupations soulevées par @buchanae , concernant les retours nommés et les erreurs contextuelles.

Je trouve les retours nommés un peu gênants ; Je pense qu'ils ne sont vraiment utiles que comme documentation. S'appuyer plus lourdement sur eux est un souci. Désolé d'être aussi vague, cependant. Je vais y réfléchir davantage et fournir des réflexions plus concrètes.

Je pense qu'il y a un réel souci que les gens s'efforcent de structurer leur code de sorte que try puisse être utilisé, et évitent donc d'ajouter du contexte aux erreurs. C'est un moment particulièrement étrange pour introduire cela, étant donné que nous venons tout juste de fournir de meilleurs moyens d'ajouter du contexte aux erreurs grâce aux fonctionnalités officielles d'encapsulation des erreurs.

Je pense que try tel que proposé rend un code beaucoup plus agréable. Voici une fonction que j'ai choisie plus ou moins au hasard dans la base de code de mon projet actuel, avec certains noms modifiés. Je suis particulièrement impressionné par le fonctionnement try lors de l'attribution de champs struct. (Cela suppose que ma lecture de la proposition est correcte et que cela fonctionne ?)

Le code existant :

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
}

Avec 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
}

Aucune perte de lisibilité, sauf peut-être qu'il est moins évident que newScanner puisse échouer. Mais alors, dans un monde avec try Go, les programmeurs seraient plus sensibles à sa présence.

@josharian Concernant main renvoyant un error : Il me semble que votre petite fonction d'assistance est tout ce qui est nécessaire pour obtenir le même effet. Je ne suis pas sûr que la modification de la signature de main soit justifiée.

Concernant l'exemple "foobar": C'est juste un mauvais exemple. Je devrais probablement le changer. Merci de l'avoir soulevé.

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

En fait, cela ne peut pas être vrai, car err sera évalué trop tôt. Il y a plusieurs façons de contourner cela, mais aucune d'entre elles n'est aussi propre que l'original (je pense défectueux) HandleErrorf. Je pense qu'il serait bon d'avoir un ou deux exemples travaillés plus réalistes d'une fonction d'assistance.

EDIT : ce bogue d'évaluation précoce est présent dans un exemple
vers la fin de la doc :

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

@adg Oui, try peut être utilisé comme vous l'utilisez dans votre exemple. Je laisse vos commentaires sur les retours nommés tels quels.

les gens peuvent vouloir faire toutes sortes de choses avec des erreurs, pas seulement en créer une nouvelle qui fait référence à l'original via sa chaîne d'erreur.

try n'essaie pas de gérer toutes les sortes de choses que les gens veulent faire avec des erreurs, seulement celles que nous pouvons trouver un moyen pratique de rendre beaucoup plus simples. Je crois que mon exemple check va dans le même sens.

D'après mon expérience, la forme la plus courante de code de gestion des erreurs est le code qui ajoute essentiellement une trace de pile, parfois avec un contexte supplémentaire. J'ai trouvé que cette trace de pile était très importante pour le débogage, où je suis un message d'erreur à travers le code.

Mais peut-être que d'autres propositions ajouteront des traces de pile à toutes les erreurs ? J'ai perdu la trace.

Dans l'exemple donné par @adg , il y a deux échecs potentiels mais pas de contexte. Si newScanner et RunMigrations ne fournissent pas eux-mêmes des messages qui vous indiquent lequel s'est mal passé, alors vous n'avez plus qu'à deviner.

Dans l'exemple donné par @adg , il y a deux échecs potentiels mais pas de contexte. Si newScanner et RunMigrations ne fournissent pas eux-mêmes des messages qui vous indiquent lequel s'est mal passé, alors vous n'avez plus qu'à deviner.

C'est vrai, et c'est le choix de conception que nous avons fait dans ce morceau de code particulier. Nous encapsulons beaucoup d'erreurs dans d'autres parties du code.

Je partage l'inquiétude de @deanveloper et d'autres que cela pourrait rendre le débogage plus difficile. Il est vrai que nous pouvons choisir de ne pas l'utiliser, mais les styles des dépendances tierces ne sont pas sous notre contrôle.
Si moins répétitif if err := ... { return err } est le point principal, je me demande si un "retour conditionnel" suffirait, comme https://github.com/golang/go/issues/27794 proposé.

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

Je pense que le ? serait un meilleur ajustement que try , et avoir toujours à chasser le defer pour erreur serait également délicat.

Cela ferme également les portes pour avoir des exceptions en utilisant try/catch pour toujours.

Cela ferme également les portes pour avoir des exceptions en utilisant try/catch pour toujours.

Je suis _plus_ que d'accord avec ça.

Je suis d'accord avec certaines des préoccupations soulevées ci-dessus concernant l'ajout de contexte à une erreur. J'essaie lentement de passer du simple renvoi d'une erreur à toujours la décorer avec un contexte, puis à la renvoyer. Avec cette proposition, je devrai complètement changer ma fonction pour utiliser des paramètres de retour nommés (ce qui me semble étrange car j'utilise à peine des retours nus).

Comme le dit @griesemer :

Encore une fois, cette proposition ne tente pas de résoudre toutes les situations de gestion d'erreurs. Je soupçonne que dans la plupart des cas, try a du sens pour un code qui ressemble maintenant essentiellement à ceci :
a, b, c, ... err := try(someFunctionCall())
si err != néant {
retour ..., euh
}
Il y a énormément de code qui ressemble à ça. Et chaque morceau de code ressemblant à celui-ci n'a pas besoin de plus de gestion des erreurs. Et là où différer n'est pas correct, on peut toujours utiliser une instruction if.

Oui, mais un bon code idiomatique ne devrait-il pas toujours envelopper/décorer ses erreurs ? Je pense que c'est pourquoi nous introduisons des mécanismes de gestion des erreurs raffinés pour ajouter des erreurs de contexte/d'encapsulation dans stdlib. Comme je le vois, cette proposition ne semble considérer que le cas d'utilisation le plus élémentaire.

De plus, cette proposition n'aborde que le cas de l'emballage/décoration de plusieurs sites de retour d'erreur possibles à un _seul endroit_, en utilisant des paramètres nommés avec un appel différé.

Mais cela ne fait rien dans le cas où l'on doit ajouter différents contextes à différentes erreurs dans une seule fonction. Par exemple, il est très essentiel de décorer les erreurs de base de données pour obtenir plus d'informations sur leur origine (en supposant qu'il n'y a pas de traces de pile)

Ceci est un exemple d'un vrai code que j'ai -

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()
}

Selon la proposition :

Si l'augmentation ou l'encapsulation des erreurs est souhaitée, il existe deux approches : s'en tenir à l'instruction if éprouvée ou, alternativement, "déclarer" un gestionnaire d'erreurs avec une instruction defer :

Je pense que cela tombera dans la catégorie "s'en tenir à l'instruction if éprouvée". J'espère que la proposition pourra être améliorée pour résoudre ce problème également.

Je suggère fortement à l'équipe Go de donner la priorité aux génériques , car c'est là que Go entend le plus de critiques, et d'attendre la gestion des erreurs. La technique d'aujourd'hui n'est pas si douloureuse (bien que go fmt devrait la laisser reposer sur une seule ligne).

Le concept try() a tous les problèmes de check de check/handle :

1. Il ne se lit pas comme Go. Les gens veulent une syntaxe d'affectation, sans le test nul ultérieur, car cela ressemble à Go. Treize réponses distinctes à vérifier / gérer l'ont suggéré; voir _Thèmes récurrents_ ici :
   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. L'imbrication des appels de fonction qui renvoient des erreurs obscurcit l'ordre des opérations et entrave le débogage. L'état des choses lorsqu'une erreur se produit, et donc la séquence d'appel, devrait être clair, mais ici ce n'est pas le cas :
   try(step4(try(step1()), try(step3(try(step2())))))
   Rappelons maintenant que la langue interdit :
   f(t ? a : b) et f(a++)

3. Il serait trivial de renvoyer des erreurs sans contexte. L'une des principales raisons d'être de check/handle était d'encourager la contextualisation.

4. Il est lié au type error et à la dernière valeur de retour. Si nous devons inspecter d'autres valeurs/types de retour pour un état exceptionnel, nous revenons à : if errno := f(); errno != 0 { ... }

5. Il n'offre pas plusieurs voies. Le code qui appelle les API de stockage ou de mise en réseau gère ces erreurs différemment de celles dues à une entrée incorrecte ou à un état interne inattendu. Mon code en fait une beaucoup plus souvent que return err :

   • log.Fatal()
   • panique() pour les erreurs qui ne devraient jamais survenir
   • enregistrer un message et réessayer

@gopherbot ajouter Go2, LanguageChange

Que diriez-vous d'utiliser seulement ? pour déballer le résultat comme rust

La raison pour laquelle nous sommes sceptiques quant à l'appel de try() peut être due à deux liaisons implicites. Nous ne pouvons pas voir la liaison pour l'erreur de valeur de retour et les arguments pour try(). Pour environ try (), nous pouvons établir une règle selon laquelle nous devons utiliser try () avec une fonction d'argument qui a une erreur dans les valeurs de retour. Mais la liaison aux valeurs de retour ne le sont pas. Je pense donc que plus d'expression est nécessaire pour que les utilisateurs comprennent ce que fait ce code.

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

• Nous ne pouvons pas utiliser try() si doSomething n'a pas %error dans les valeurs de retour.
• Nous ne pouvons pas utiliser try() si foo() n'a pas d'erreur dans la dernière des valeurs de retour.

Il est difficile d'ajouter de nouvelles exigences/fonctionnalités à la syntaxe existante.

Pour être honnête, je pense que foo() devrait également avoir %error.

Ajouter 1 règle supplémentaire

• %error ne peut être qu'un dans la liste des valeurs de retour d'une fonction.

Dans le document de conception détaillée, j'ai remarqué que dans une itération précédente, il avait été suggéré de transmettre un gestionnaire d'erreurs à la fonction intégrée try. Comme ça:

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

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

ou encore mieux, comme ceci :

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

Bien que, comme l'indique le document, cela soulève plusieurs questions, je pense que cette proposition serait beaucoup plus souhaitable et utile si elle avait conservé cette possibilité de spécifier éventuellement une telle fonction de gestionnaire d'erreurs ou de fermeture.

Deuxièmement, cela ne me dérange pas qu'une fonction intégrée puisse provoquer le retour de la fonction, mais, pour faire un peu de vélo, le nom 'try' est trop court pour suggérer qu'il peut provoquer un retour. Donc un nom plus long, comme attempt me semble mieux.

EDIT: Troisièmement, idéalement, le langage go devrait d'abord gagner des génériques, où un cas d'utilisation important serait la possibilité d'implémenter cette fonction d'essai en tant que générique, afin que le bikeshedding puisse se terminer et que chacun puisse obtenir la gestion des erreurs qu'il préfère lui-même.

Les nouvelles des hackers ont un certain intérêt : try ne se comporte pas comme une fonction normale (elle peut revenir), il n'est donc pas bon de lui donner une syntaxe semblable à une fonction. Une syntaxe return ou defer serait plus appropriée :

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 le contre-argument commun à cela est que panic est également une fonction intégrée de modification du flux de contrôle. Personnellement, je ne suis pas d'accord avec cela, mais c'est correct.

1. En écho à @deanveloper ci- dessus , ainsi qu'aux commentaires similaires d'autres personnes, j'ai très peur que nous sous-estimions les coûts d'ajout d'un nouveau mot-clé quelque peu subtil et, en particulier lorsqu'il est intégré dans d'autres appels de fonction, facilement négligé qui gère le contrôle de la pile d'appels couler. panic(...) est une exception relativement claire (jeu de mots non voulu) à la règle selon laquelle return est le seul moyen de sortir d'une fonction. Je ne pense pas que nous devrions utiliser son existence comme justification pour en ajouter un troisième.
2. Cette proposition canoniserait le renvoi d'une erreur non encapsulée comme comportement par défaut, et reléguerait les erreurs d'encapsulation comme quelque chose auquel vous devez vous inscrire, avec une cérémonie supplémentaire. Mais, d'après mon expérience, c'est précisément l'inverse des bonnes pratiques. J'espère qu'une proposition dans cet espace faciliterait, ou du moins pas plus difficile, l'ajout d'informations contextuelles aux erreurs sur le site d'erreur.

peut-être pouvons-nous ajouter une variante avec une fonction d'augmentation optionnelle quelque chose comme tryf avec cette sémantique :

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

traduit ceci

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

dans ce

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

puisqu'il s'agit d'un choix explicite (au lieu d'utiliser try ), nous pouvons trouver des réponses raisonnables aux questions de la version précédente de cette conception. par exemple, si la fonction d'augmentation est nulle, ne faites rien et renvoyez simplement l'erreur d'origine.

Je crains que try supplante la gestion traditionnelle des erreurs et que cela rende l'annotation des chemins d'erreur plus difficile en conséquence.

Le code qui gère les erreurs en enregistrant les messages et en mettant à jour les compteurs de télémétrie sera considéré comme défectueux ou inapproprié à la fois par les linters et les développeurs qui s'attendent à tout try .

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

Go est un langage extrêmement social avec des idiomes communs renforcés par des outils (fmt, lint, etc.). Veuillez garder à l'esprit les ramifications sociales de cette idée - il y aura une tendance à vouloir l'utiliser partout.

@politician , désolé, mais le mot que vous cherchez n'est pas _social_ mais _opinionated_. Go est un langage de programmation opiniâtre. Pour le reste, je suis plutôt d'accord avec ce que tu veux dire.

@beoran Les outils communautaires comme Godep et les différents linters démontrent que Go est à la fois opiniâtre et social, et de nombreux drames avec le langage découlent de cette combinaison. Espérons que nous puissions tous les deux convenir que try ne devrait pas être le prochain drame.

@politicien Merci d'avoir précisé, je ne l'avais pas compris de cette façon. Je peux certainement convenir que nous devrions essayer d'éviter le drame.

Je suis confus à ce sujet.

Extrait du blog : Les erreurs sont des valeurs , de mon point de vue, elles sont conçues pour être valorisées pour ne pas être ignorées.

Et je crois ce que Rop Pike a dit, "Les valeurs peuvent être programmées, et puisque les erreurs sont des valeurs, les erreurs peuvent être programmées.".

Nous ne devrions pas considérer error comme exception , c'est comme importer de la complexité non seulement pour la réflexion mais aussi pour le codage si nous le faisons.

"Utilisez le langage pour simplifier votre gestion des erreurs." --Rob Pike

Et plus, nous pouvons revoir cette diapositive

Une situation où je trouve la vérification des erreurs via if particulièrement gênante est lors de la fermeture de fichiers (par exemple sur NFS). Je suppose que, actuellement, nous sommes censés écrire ce qui suit, si des retours d'erreur de .Close() sont possibles ?

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

defer try(r.Close()) pourrait-il être un bon moyen d'avoir une syntaxe gérable pour traiter de telles erreurs ? Au moins, il serait logique d'ajuster l'exemple CopyFile() dans la proposition d'une certaine manière, pour ne pas ignorer les erreurs de r.Close() et w.Close() .

@seehuhn Votre exemple ne sera pas compilé car la fonction différée n'a pas de type de retour.

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

Fonctionnera comme prévu. La clé est la valeur de retour nommée.

J'aime la proposition mais je pense que l'exemple de @seehuhn devrait également être abordé :

defer try(w.Close())

renverrait l'erreur de Close() uniquement si l'erreur n'était pas déjà définie.
Ce modèle est si souvent utilisé...

Je suis d'accord avec les préoccupations concernant l'ajout de contexte aux erreurs. Je le vois comme l'une des meilleures pratiques qui garde les messages d'erreur très conviviaux (et clairs) et facilite le processus de débogage.

La première chose à laquelle j'ai pensé était de remplacer le fmt.HandleErrorf par une fonction tryf , qui préfixe l'erreur avec un contexte supplémentaire.

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

Par exemple (à partir d'un vrai code que j'ai):

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)
    }
    // ...
}

Peut être changé en quelque chose comme :

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))
    // ...
}

Ou, si je prends l'exemple de @agnivade :

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")
}

Cependant, @josharian a soulevé un bon point qui me fait hésiter sur cette solution :

Tel qu'il est écrit, cependant, il déplace le formatage de style fmt d'un paquet vers le langage lui-même, ce qui ouvre une boîte de Pandore.

Je suis totalement d'accord avec cette proposition et je peux voir ses avantages à travers un certain nombre d'exemples.

Ma seule préoccupation avec la proposition est la dénomination de try , je pense que ses connotations avec d'autres langues peuvent fausser les perceptions des développeurs sur son objectif lorsqu'il vient d'autres langues. Java vient trouver ici.

Pour moi, je préférerais que la fonction intégrée s'appelle pass . Je pense que cela donne une meilleure représentation de ce qui se passe. Après tout, vous ne gérez pas l'erreur - vous la renvoyez plutôt pour qu'elle soit gérée par l'appelant. try donne l'impression que l'erreur a été traitée.

C'est un pouce vers le bas de moi, principalement parce que le problème qu'il vise à résoudre ("le passe-partout si les instructions sont généralement associées à la gestion des erreurs") n'est tout simplement pas un problème pour moi. Si toutes les vérifications d'erreur étaient simplement if err != nil { return err } , alors je pourrais voir une certaine valeur dans l'ajout de sucre syntaxique pour cela (bien que Go soit un langage relativement sans sucre par inclination).

En fait, ce que je veux faire en cas d'erreur non nulle varie assez considérablement d'une situation à l'autre. Peut-être que je veux t.Fatal(err) . Peut-être que je veux ajouter un message de décoration return fmt.Sprintf("oh no: %v", err) . Peut-être que je viens de consigner l'erreur et de continuer. Peut-être que j'ai défini un indicateur d'erreur sur mon objet SafeWriter et que je continue, en vérifiant l'indicateur à la fin d'une séquence d'opérations. Peut-être que je dois prendre d'autres mesures. Aucun de ceux-ci ne peut être automatisé avec try . Donc, si l'argument pour try est qu'il éliminera tous les blocs if err != nil , cet argument ne tient pas.

Cela éliminera-t-il _certains_ d'entre eux ? Sûr. Est-ce une proposition intéressante pour moi ? Meh. Je ne suis vraiment pas concerné. Pour moi, if err != nil fait partie du Go, comme les accolades, ou defer . Je comprends que cela semble verbeux et répétitif pour les personnes qui découvrent Go, mais les personnes qui découvrent Go ne sont pas les mieux placées pour apporter des changements radicaux à la langue, pour tout un tas de raisons.

La barre pour des changements significatifs à Go a traditionnellement été que le changement proposé doit résoudre un problème qui est (A) significatif, (B) affecte beaucoup de gens, et (C) est bien résolu par la proposition. Je ne suis convaincu sur aucun de ces trois critères. Je suis assez satisfait de la gestion des erreurs de Go telle qu'elle est.

Pour faire écho à @peterbourgon et @deanveloper , l'une de mes choses préférées à propos de Go est que le flux de code est clair et que panic() n'est pas traité comme un mécanisme de contrôle de flux standard comme c'est le cas en Python.

Concernant le débat sur la panique, panic() apparaît presque toujours seul sur une ligne car il n'a aucune valeur. Vous ne pouvez pas fmt.Println(panic("oops")) . Cela augmente considérablement sa visibilité et le rend beaucoup moins comparable à try() que les gens ne le prétendent.

S'il doit y avoir une autre construction de contrôle de flux pour les fonctions, je préférerais _de loin_ qu'il s'agisse d'une instruction garantie d'être l'élément le plus à gauche sur une ligne.

L'un des exemples de la proposition me pose problème :

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

Le flux de contrôle devient vraiment moins évident et très obscur.

Cela va également à l'encontre de l'intention initiale de Rob Pike selon laquelle toutes les erreurs doivent être traitées explicitement.

Bien qu'une réaction à cela puisse être "alors ne l'utilisez pas", le problème est que d'autres bibliothèques l'utiliseront, et les déboguer, les lire et les utiliser devient plus problématique. Cela motivera mon entreprise à ne jamais adopter go 2 et à commencer à n'utiliser que des bibliothèques qui n'utilisent pas try . Si je ne suis pas seul avec cela, cela pourrait conduire à une division à la python 2/3.

De plus, le nommage de try impliquera automatiquement que catch finira par apparaître dans la syntaxe, et nous redeviendrons Java.

Donc, à cause de tout cela, je suis _fortement_ contre cette proposition.

Je n'aime pas le nom try . Cela implique une _tentative_ de faire quelque chose avec un risque élevé d'échec (j'ai peut-être un préjugé culturel contre _try_ car je ne suis pas de langue maternelle anglaise), alors qu'à la place try serait utilisé au cas où nous nous attendrions à des échecs rares (motivation à vouloir réduire la verbosité de la gestion des erreurs) et sont optimistes. De plus, try dans cette proposition _attrape_ une erreur pour la renvoyer plus tôt. J'aime la suggestion pass de @HiImJC.

Outre le nom, je trouve gênant d'avoir une instruction de type return maintenant cachée au milieu des expressions. Cela rompt le style de flux Go. Cela rendra les revues de code plus difficiles.

En général, je trouve que cette proposition ne profitera qu'au programmeur paresseux qui a maintenant une arme pour un code plus court et encore moins de raison de faire l'effort d'envelopper les erreurs. Comme cela va aussi rendre les révisions plus difficiles (retour en milieu d'expression), je pense que cette proposition va à l'encontre de l'objectif "programmation à l'échelle" du Go.

L'une de mes choses préférées à propos de Go que je dis généralement lorsque je décris le langage est qu'il n'y a qu'une seule façon de faire les choses, pour la plupart des choses. Cette proposition va un peu à l'encontre de ce principe en offrant plusieurs façons de faire la même chose. Je pense personnellement que ce n'est pas nécessaire et que cela enlèverait plutôt que d'ajouter à la simplicité et à la lisibilité du langage.

J'aime cette proposition dans l'ensemble. L'interaction avec defer semble suffisante pour fournir un moyen ergonomique de renvoyer une erreur tout en ajoutant un contexte supplémentaire. Bien qu'il serait bien de résoudre le problème que @josharian a souligné sur la façon d'inclure l'erreur d'origine dans le message d'erreur encapsulé.

Ce qui manque, c'est une manière ergonomique d'interagir avec la ou les propositions d'inspection des erreurs sur la table. Je pense que les API devraient être très délibérées quant aux types d'erreurs qu'elles renvoient, et la valeur par défaut devrait probablement être "les erreurs renvoyées ne sont en aucun cas inspectables". Il devrait alors être facile de passer à un état où les erreurs sont inspectables de manière précise, comme documenté par la signature de la fonction ("Il signale une erreur de type X dans la circonstance A et une erreur de type Y dans la circonstance B").

Malheureusement, à partir de maintenant, cette proposition rend l'option la plus ergonomique la plus indésirable (pour moi); passant aveuglément par des types d'erreurs arbitraires. Je pense que ce n'est pas souhaitable car cela encourage à ne pas penser aux types d'erreurs que vous renvoyez et à la façon dont les utilisateurs de votre API les consommeront. La commodité supplémentaire de cette proposition est certainement agréable, mais je crains qu'elle n'encourage un mauvais comportement car la commodité perçue l'emportera sur la valeur perçue de réfléchir attentivement aux informations d'erreur que vous fournissez (ou divulguez).

Un pansement serait si les erreurs renvoyées par try étaient converties en erreurs qui ne sont pas "déballables". Malheureusement, cela a également des inconvénients assez graves, car cela fait en sorte que tout defer ne peut pas inspecter les erreurs lui-même. De plus, cela empêche l'utilisation où try renverra une erreur d'un type souhaitable (c'est-à-dire les cas d'utilisation où try est utilisé avec précaution plutôt qu'avec insouciance).

Une autre solution consisterait à réutiliser l'idée (rejetée) d'avoir un deuxième argument facultatif à try pour définir/ajouter à la liste blanche le ou les types d'erreur pouvant être renvoyés par ce site. C'est un peu gênant car nous avons deux manières différentes de définir un "type d'erreur", soit par valeur ( io.EOF etc) soit par type ( *os.PathError , *exec.ExitError ). Il est facile de spécifier des types d'erreurs qui sont des valeurs en tant qu'arguments d'une fonction, mais plus difficile de spécifier des types. Je ne sais pas comment gérer cela, mais je lance l'idée là-bas.

Le problème signalé par @josharian peut être évité en retardant l'évaluation de err :

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

Ça n'a pas l'air génial, mais ça devrait marcher. Je préférerais cependant si cela peut être résolu en ajoutant un nouveau verbe/indicateur de formatage pour les pointeurs d'erreur, ou peut-être pour les pointeurs en général, qui imprime la valeur déréférencée comme avec plain %v . Pour les besoins de l'exemple, appelons-le %*v :

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

Le hic mis à part, je pense que cette proposition semble prometteuse, mais il semble crucial de garder l'ergonomie de l'ajout de contexte aux erreurs sous contrôle.

Éditer:

Une autre approche consiste à envelopper le pointeur d'erreur dans une structure qui implémente Stringer :

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

...

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

Quelques choses de mon point de vue. Pourquoi sommes-nous si soucieux d'économiser quelques lignes de code ? Je considère cela dans le même sens que les petites fonctions considérées comme nuisibles .

De plus, je trouve qu'une telle proposition enlèverait la responsabilité de gérer correctement l'erreur à une "magie" dont je crains qu'elle ne soit simplement abusée et encourage la paresse entraînant un code de mauvaise qualité et des bogues.

La proposition, telle qu'elle est indiquée, comporte également un certain nombre de comportements peu clairs, ce qui est déjà problématique par rapport à _explicit_ supplémentaires ~ 3 lignes plus claires.

Nous utilisons actuellement le modèle de report avec parcimonie en interne. Il y a un article ici qui a eu un accueil mitigé lorsque nous l'avons écrit - https://bet365techblog.com/better-error-handling-in-go

Cependant, nous l'avons utilisé en prévision de la progression de la proposition check / handle .

Check/handle était une approche beaucoup plus complète pour rendre la gestion des erreurs plus concise. Son bloc handle a conservé la même portée de fonction que celle dans laquelle il a été défini, alors que toutes les instructions defer sont de nouveaux contextes avec une quantité, quelle qu'en soit la hauteur, de surcharge. Cela semblait être plus conforme aux idiomes de go, en ce sens que si vous vouliez le comportement de "retourner simplement l'erreur quand elle se produit", vous pouviez le déclarer explicitement comme handle { return err } .

Defer repose évidemment sur le maintien de la référence err également, mais nous avons vu des problèmes survenir en masquant la référence de l'erreur avec des vars à portée de bloc. Il n'est donc pas suffisamment infaillible pour être considéré comme le moyen standard de gérer les erreurs au go.

try , dans ce cas, ne semble pas trop résoudre et je partage la même crainte que d'autres que cela conduirait simplement à des implémentations paresseuses, ou à des implémentations qui sur-utilisent le modèle de report.

Si la gestion des erreurs basée sur le report va être une chose, alors quelque chose comme ceci devrait probablement être ajouté au package d'erreurs :

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

Ignorer les erreurs des instructions Close différées est un problème assez courant. Il devrait y avoir un outil standard pour l'aider.

Une fonction intégrée qui renvoie est plus difficile à vendre qu'un mot-clé qui fait la même chose.
Je l'aimerais plus s'il s'agissait d'un mot-clé comme c'est le cas dans Zig[1].

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

Les fonctions intégrées, dont la signature de type ne peut pas être exprimée à l'aide du système de type du langage, et dont le comportement confond ce qu'est normalement une fonction, ressemblent à une trappe de sortie qui peut être utilisée à plusieurs reprises pour éviter l'évolution réelle du langage.

Nous sommes habitués à reconnaître immédiatement les instructions de retour (et les paniques) car c'est ainsi que ce type de flux de contrôle est exprimé en Go (et dans de nombreux autres langages). Il ne semble pas exagéré que nous reconnaissions également l'essai comme un changement de flux de contrôle après s'y être habitué, tout comme nous le faisons pour le retour. Je ne doute pas qu'un bon support IDE aidera également à cela.

Je pense que c'est assez tiré par les cheveux. Dans le code gofmt, un retour correspond toujours à /^\t*return / - c'est un modèle très trivial à repérer à l'œil nu, sans aucune aide. try , d'autre part, peut apparaître n'importe où dans le code, imbriqué arbitrairement profondément dans les appels de fonction. Aucune formation ne nous permettra de repérer immédiatement tous les flux de contrôle dans une fonction sans l'aide d'outils.

De plus, une fonctionnalité qui dépend d'un "bon support IDE" sera désavantagée dans tous les environnements où il n'y a pas de bon support IDE. Les outils de revue de code me viennent immédiatement à l'esprit – Gerrit mettra-t-il en évidence tous les essais pour moi ? Qu'en est-il des personnes qui choisissent de ne pas utiliser les IDE ou la mise en évidence de code fantaisiste, pour diverses raisons ? Acme commencera-t-il à mettre en évidence try ?

Une fonctionnalité de langage doit être facile à comprendre en elle-même et ne pas dépendre de la prise en charge de l'éditeur.

@kungfusheep J'aime cet article. Prendre soin d'envelopper dans un report seul augmente déjà un peu la lisibilité sans try .

Je suis dans le camp qui ne pense pas que les erreurs de Go soient vraiment un problème. Même ainsi, if err != nil { return err } peut être tout à fait le bégaiement sur certaines fonctions. J'ai écrit des fonctions qui nécessitaient une vérification des erreurs après presque chaque instruction et aucune n'avait besoin d'une gestion spéciale autre que wrap et return. Parfois, il n'y a tout simplement pas de structure Buffer intelligente qui rendra les choses plus agréables. Parfois, il s'agit simplement d'une étape critique différente après l'autre et vous devez simplement court-circuiter si quelque chose ne va pas.

Bien que try rendrait certainement ce code beaucoup plus facile à lire tout en étant entièrement rétrocompatible, je conviens que try n'est pas une fonctionnalité indispensable, donc si les gens ont trop peur de il vaut peut-être mieux ne pas l'avoir.

La sémantique est assez claire cependant. Chaque fois que vous voyez try , soit il suit le bon chemin, soit il revient. Je ne peux vraiment pas faire plus simple que ça.

Cela ressemble à une macro spéciale en boîtier.

@dominikh try correspond toujours à /try\(/ donc je ne sais pas vraiment ce que vous voulez dire. Il est tout aussi consultable et chaque éditeur dont j'ai entendu parler dispose d'une fonction de recherche.

@qrpnxz Je pense que le point qu'il essayait de faire valoir n'est pas que vous ne pouvez pas le rechercher par programme, mais qu'il est plus difficile de le rechercher avec vos yeux. L'expression rationnelle n'était qu'une analogie, mettant l'accent sur le /^\t* , ce qui signifie que tous les retours se distinguent clairement en étant au début d'une ligne (en ignorant les espaces en tête).

En y réfléchissant davantage, il devrait y avoir quelques fonctions d'assistance communes. Peut-être devraient-ils être dans un package appelé "différé".

Abordant la proposition d'un check avec un format pour éviter de nommer le retour, vous pouvez simplement le faire avec une fonction qui vérifie nil, comme ceci

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

Ceci peut être utilisé sans retour nommé comme ceci :

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

Le fmt.HandleError proposé pourrait être placé dans le package différé à la place et ma fonction d'assistance errors.Defer pourrait être appelée deferred.Exec et il pourrait y avoir un exec conditionnel pour que les procédures s'exécutent uniquement si l'erreur est non nulle.

En le mettant ensemble, vous obtenez quelque chose comme

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
}

Un autre exemple:

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()
}

Cette proposition nous fait passer de if err != nil partout à try partout. Il déplace le problème proposé et ne le résout pas.

Cependant, je dirais que le mécanisme actuel de gestion des erreurs n'est pas un problème pour commencer. Nous avons juste besoin d'améliorer l' outillage et de contrôler tout cela.

De plus, je dirais que if err != nil est en fait plus lisible que try car il n'encombre pas la ligne du langage de logique métier, mais se trouve plutôt juste en dessous :

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

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

}

Et si Go devait être plus magique dans sa gestion des erreurs, pourquoi ne pas le posséder totalement. Par exemple, Go peut appeler implicitement la fonction intégrée try si un utilisateur n'attribue pas d'erreur. Par exemple:

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()
}

Pour moi, cela résoudrait en fait le problème de la redondance au prix de la magie et de la lisibilité potentielle.

Par conséquent, je propose que nous résolvions vraiment le "problème" comme dans l'exemple ci-dessus ou que nous conservions la gestion des erreurs actuelle, mais au lieu de changer le langage pour résoudre la redondance et l'emballage, nous ne changeons pas le langage mais nous améliorons l' outillage et la vérification de code pour améliorer l'expérience.

Par exemple, dans VSCode, il y a un extrait appelé iferr si vous le tapez et appuyez sur Entrée, il se transforme en une déclaration complète de gestion des erreurs... par conséquent, l'écrire ne me semble jamais fastidieux, et lire plus tard est mieux .

@josharian

Bien que ce ne soit pas "un changement de bibliothèque modeste", nous pourrions également envisager d'accepter l'erreur func main().

Le problème avec cela est que toutes les plates-formes n'ont pas une sémantique claire sur ce que cela signifie. Votre réécriture fonctionne bien dans les programmes Go "traditionnels" exécutés sur un système d'exploitation complet - mais dès que vous écrivez un micrologiciel de microcontrôleur ou même simplement WebAssembly, la signification os.Exit(1) n'est pas très claire. Actuellement, os.Exit est un appel de bibliothèque, donc les implémentations Go sont libres de ne pas le fournir. La forme de main est cependant un problème de langage.

Une question sur la proposition à laquelle il est probablement préférable de répondre par "non": comment try interagit-il avec les arguments variadiques ? C'est le premier cas d'une fonction variadique (ish) qui n'a pas ses variadic-nes dans le dernier argument. Est-ce autorisé :

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

Laissant de côté pourquoi vous feriez cela. Je soupçonne que la réponse est "non" (sinon le suivi est "et si la longueur de la tranche étendue est de 0). Il suffit d'en parler pour que cela puisse être gardé à l'esprit lors de la formulation de la spécification.

• Plusieurs des plus grandes fonctionnalités de go sont que les fonctions intégrées actuelles garantissent un flux de contrôle clair, la gestion des erreurs est explicite et encouragée, et les développeurs sont fortement dissuadés d'écrire du code "magique". La proposition try n'est pas cohérente avec ces principes de base, car elle favorisera la sténographie au détriment de la lisibilité du flux de contrôle.
• Si cette proposition est adoptée, envisagez peut-être de faire de la fonction intégrée try une déclaration au lieu d'une fonction . Ensuite, il est plus cohérent avec d'autres instructions de flux de contrôle comme if . De plus, la suppression des parenthèses imbriquées améliore légèrement la lisibilité.
• Encore une fois, si la proposition est adoptée, mettez-la peut-être en œuvre sans utiliser defer ou similaire. Il ne peut déjà pas être implémenté en pur go (comme l'ont souligné d'autres), il peut donc tout aussi bien utiliser une implémentation plus efficace sous le capot.

J'y vois deux problèmes :

1. Il met BEAUCOUP de code imbriqué dans les fonctions. Cela ajoute beaucoup de charge cognitive supplémentaire, en essayant d'analyser le code dans votre tête.

1. Cela nous donne des endroits où le code peut sortir du milieu d'une instruction.

Je pense que le numéro 2 est bien pire. Tous les exemples ici sont des appels simples qui renvoient une erreur, mais ce qui est beaucoup plus insidieux, c'est ceci :

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

Ce code peut sortir au milieu de ce sprintf, et il sera SUPER facile de rater ce fait.

Mon vote est non. Cela n'améliorera pas le code go. Cela ne facilitera pas la lecture. Cela ne le rendra pas plus robuste.

Je l'ai déjà dit, et cette proposition en est un exemple - j'ai l'impression que 90% des plaintes concernant Go sont "Je ne veux pas écrire d'instruction if ou de boucle". Cela supprime certaines instructions if très simples, mais ajoute une charge cognitive et permet de manquer facilement des points de sortie pour une fonction.

Je veux juste souligner que vous ne pouvez pas l'utiliser dans la main et que cela peut être déroutant pour les nouveaux utilisateurs ou lors de l'enseignement. Évidemment, cela s'applique à toute fonction qui ne renvoie pas d'erreur, mais je pense que main est spécial car il apparaît dans de nombreux exemples.

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

Je ne suis pas sûr que faire essayer de paniquer dans le main soit acceptable non plus.

De plus, cela ne serait pas particulièrement utile dans les tests ( func TestFoo(t* testing.T) ) ce qui est regrettable :(

Le problème que j'ai avec cela est qu'il suppose que vous voulez toujours simplement renvoyer l'erreur lorsqu'elle se produit. Lorsque vous souhaitez peut-être ajouter du contexte à l'erreur et la renvoyer ou peut-être souhaitez-vous simplement vous comporter différemment lorsqu'une erreur se produit. Cela dépend peut-être du type d'erreur renvoyé.

Je préférerais quelque chose qui s'apparente à un try/catch qui pourrait ressembler à

En supposant foo() défini comme

func foo() (int, error) {}

Vous pourriez alors faire

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

Ce qui se traduit par

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
}

Pour moi, la gestion des erreurs est l'une des parties les plus importantes d'une base de code.
Déjà trop de code go est if err != nil { return err } , renvoyant une erreur du plus profond de la pile sans ajouter de contexte supplémentaire, ou même (peut-être) pire en ajoutant du contexte en masquant l'erreur sous-jacente avec fmt.Errorf wraping.

Fournir un nouveau mot-clé qui est une sorte de magie qui ne fait que remplacer if err != nil { return err } semble être une route dangereuse à suivre.
Maintenant, tout le code sera simplement enveloppé dans un appel pour essayer. C'est assez correct (bien que la lisibilité soit nulle) pour le code qui ne traite que des erreurs dans le package telles que :

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

Mais je dirais que l'exemple donné est vraiment horrible et laisse essentiellement l'appelant essayer de comprendre une erreur qui est vraiment profonde dans la pile, un peu comme la gestion des exceptions.
Bien sûr, c'est au développeur de faire ce qu'il faut ici, mais cela donne au développeur un excellent moyen de ne pas se soucier de ses erreurs avec peut-être un "nous corrigerons cela plus tard" (et nous savons tous comment cela se passe ).

J'aimerais que nous examinions le problème d'un point de vue différent de *"comment pouvons-nous réduire la répétition" et plus sur "comment pouvons-nous rendre la gestion des erreurs (correcte) plus simple et les développeurs plus productifs".
Nous devrions réfléchir à la manière dont cela affectera l'exécution du code de production.

*Remarque : Cela ne réduit pas réellement la répétition, change simplement ce qui est répété, tout en rendant le code moins lisible car tout est enfermé dans un try() .

Un dernier point : lire la proposition au début ça semble sympa, puis on commence à rentrer dans tous les pièges (du moins ceux listés) et c'est comme "ok ouais c'est trop".

Je me rends compte qu'une grande partie de cela est subjectif, mais c'est quelque chose qui m'importe. Cette sémantique est extrêmement importante.
Ce que je veux voir, c'est un moyen de simplifier l'écriture et la maintenance du code de niveau de production, de sorte que vous puissiez tout aussi bien faire des erreurs "correctes", même pour le code de niveau POC/démo.

Puisque le contexte d'erreur semble être un thème récurrent...

Hypothèse : la plupart des fonctions Go renvoient (T, error) au lieu de (T1, T2, T3, error)

Et si, au lieu de définir try comme try(T1, T2, T3, error) (T1, T2, T3) nous le définissions comme
try(func (args) (T1, T2, T3, error))(T1, T2, T3) ? (c'est une approximation)

c'est-à-dire que la structure syntaxique d'un appel try est toujours un premier argument qui est une expression renvoyant plusieurs valeurs, dont la dernière est une erreur.

Ensuite, tout comme make , cela ouvre la porte à une forme d'appel à 2 arguments, où le deuxième argument est le contexte de l'essai (par exemple, une chaîne fixe, une chaîne avec un %v , une fonction qui prend un argument d'erreur et renvoie une autre erreur, etc.)

Cela permet toujours l'enchaînement pour le cas (T, error) mais vous ne pouvez plus enchaîner plusieurs retours qui ne sont généralement pas requis par l'OMI.

@ cpuguy83 Si vous lisez la proposition, vous verrez que rien ne vous empêche d'envelopper l'erreur. En fait, il existe plusieurs façons de le faire tout en utilisant try . Beaucoup de gens semblent supposer que pour une raison quelconque.

if err != nil { return err } équivaut à "nous corrigerons cela plus tard" à try , sauf que c'est plus ennuyeux lors du prototypage.

Je ne sais pas comment les choses étant à l'intérieur d'une paire de parenthèses sont moins lisibles que les étapes de fonction étant toutes les quatre lignes de passe-partout non plus.

Ce serait bien si vous souligniez certains de ces "pièges" particuliers qui vous dérangent puisque c'est le sujet.

La lisibilité semble être un problème, mais qu'en est-il de go fmt présentant try() pour qu'il se démarque, quelque chose comme :

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

@MrTravisB

Le problème que j'ai avec cela est qu'il suppose que vous voulez toujours simplement renvoyer l'erreur lorsqu'elle se produit.

Je ne suis pas d'accord. Cela suppose que vous vouliez le faire assez souvent pour justifier un raccourci pour cela. Si vous ne le faites pas, cela ne vous empêchera pas de gérer clairement les erreurs.

Lorsque vous souhaitez peut-être ajouter du contexte à l'erreur et la renvoyer ou peut-être souhaitez-vous simplement vous comporter différemment lorsqu'une erreur se produit.

La proposition décrit un modèle pour ajouter un contexte à l'échelle du bloc aux erreurs. @josharian a cependant souligné qu'il y avait une erreur dans les exemples et que la meilleure façon de l'éviter n'était pas claire. J'ai écrit quelques exemples de façons de le gérer.

Pour un contexte d'erreur plus spécifique, encore une fois, try fait une chose, et si vous ne voulez pas cette chose, n'utilisez pas try .

@boomlinde Exactement ce que je veux dire. Cette proposition tente de résoudre un cas d'utilisation singulier plutôt que de fournir un outil pour résoudre le problème plus large de la gestion des erreurs. Je pense que la question fondamentale est exactement ce que vous avez souligné.

Cela suppose que vous vouliez le faire assez souvent pour justifier un raccourci pour cela.

À mon avis et par expérience, ce cas d'utilisation est une petite minorité et ne justifie pas une syntaxe abrégée.

De plus, l'approche consistant à utiliser defer pour gérer les erreurs pose des problèmes dans la mesure où elle suppose que vous souhaitez gérer toutes les erreurs possibles de la même manière. Les relevés defer ne peuvent pas être annulés.

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

n := try(foo())

x : try(foo2())

Que se passe-t-il si je veux une gestion des erreurs différente pour les erreurs qui pourraient être renvoyées de foo() vs foo2() ?

@MrTravisB

Que se passe-t-il si je veux une gestion des erreurs différente pour les erreurs qui pourraient être renvoyées par foo() vs foo2() ?

Ensuite, vous utilisez autre chose. C'est le point que @boomlinde faisait valoir.

Peut-être que vous ne voyez pas souvent ce cas d'utilisation personnellement, mais beaucoup de gens le font, et l'ajout try ne vous affecte pas vraiment. En fait, plus le cas d'utilisation est rare pour vous, moins cela vous affecte que try soit ajouté.

@qrpnxz

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

(oui, je comprends qu'il y a ReadFile et que cet exemple particulier n'est pas la meilleure façon de copier des données quelque part, pas le point)

Cela demande plus d'efforts à lire car vous devez analyser le try en ligne. La logique d'application est enveloppée dans un autre appel.
Je dirais également qu'un gestionnaire d'erreurs defer ici ne serait pas bon, sauf pour simplement envelopper l'erreur avec un nouveau message ... ce qui est bien mais il y a plus à traiter les erreurs que de le rendre facile pour le humain de lire ce qui s'est passé.

Dans Rust, au moins l'opérateur est un suffixe ( ? ajouté à la fin d'un appel) qui n'impose pas de charge supplémentaire pour déterrer la logique réelle.

Contrôle de flux basé sur l'expression

panic peut être une autre fonction de contrôle de flux, mais elle ne renvoie pas de valeur, ce qui en fait une instruction. Comparez cela à try , qui est une expression et peut apparaître n'importe où.

recover a une valeur et affecte le contrôle de flux, mais doit apparaître dans une instruction defer . Ces defer s sont généralement des littéraux de fonction, recover n'est appelé qu'une seule fois, et donc recover apparaît également comme une instruction. Encore une fois, comparez cela à try qui peut se produire n'importe où.

Je pense que ces points signifient que try rend beaucoup plus difficile de suivre le flux de contrôle d'une manière que nous n'avons pas eue auparavant, comme cela a été souligné précédemment, mais je n'ai pas vu la distinction entre les déclarations et les expressions souligné.

Une autre proposition

Autoriser les déclarations telles que

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

être formaté sur une ligne par gofmt lorsque le bloc ne contient qu'une instruction return et que cette instruction ne contient pas de nouvelles lignes. Par exemple:

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

Raisonnement

• Il ne nécessite aucun changement de langue
• La règle de formatage est simple et claire
• La règle peut être conçue pour être opt-in où gofmt conserve les retours à la ligne s'ils existent déjà (comme les littéraux de structure). L'activation permet également à l'auteur de mettre l'accent sur la gestion des erreurs
• Si ce n'est pas le cas, le code peut être automatiquement transféré vers le nouveau style avec un appel à gofmt
• C'est seulement pour les instructions return , donc il ne sera pas inutilement abusé pour coder le golf
• Interagit bien avec les commentaires décrivant pourquoi certaines erreurs peuvent se produire et pourquoi elles sont renvoyées. L'utilisation de nombreuses expressions imbriquées try gère cela mal
• Il réduit l'espace vertical de gestion des erreurs de 66 %
• Aucun flux de contrôle basé sur l'expression
• Le code est lu beaucoup plus souvent qu'il n'est écrit, il doit donc être optimisé pour le lecteur. Le code répétitif prenant moins de place est utile au lecteur, où try se penche davantage vers l'auteur
• Les gens ont déjà proposé try existant sur plusieurs lignes. Par exemple ce commentaire ou ce commentaire qui introduit un style comme

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

• Le style "essayer sur sa propre ligne" supprime toute ambiguïté sur la err renvoyée. Par conséquent, je soupçonne que ce formulaire sera couramment utilisé. Autoriser une ligne si les blocs est presque la même chose, sauf qu'il est également explicite sur les valeurs de retour
• Il ne favorise pas l'utilisation de retours nommés ou d'emballages basés defer peu clairs. Les deux lèvent la barrière aux erreurs d'emballage et le premier peut nécessiter des modifications de godoc
• Il n'est pas nécessaire de discuter du moment où utiliser try par rapport à l'utilisation traditionnelle de la gestion des erreurs
• N'empêche pas de faire try ou autre chose dans le futur. Le changement peut être positif même si try est accepté
• Aucune interaction négative avec la bibliothèque testing ou les fonctions main . En fait, si la proposition autorise n'importe quelle instruction sur une seule ligne au lieu de simplement retourner, cela peut réduire l'utilisation des bibliothèques basées sur des assertions. Considérer

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

• Aucune interaction négative avec la vérification d'erreurs spécifiques. Considérer

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

En résumé, cette proposition a un petit coût, peut être conçue pour être opt-in, n'empêche pas d'autres modifications puisqu'elle est uniquement stylistique et réduit la difficulté de lire le code de gestion des erreurs verbeux tout en gardant tout explicite. Je pense que cela devrait au moins être considéré comme une première étape avant de faire tapis sur try .

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

Avec essai

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
}

Avec ça

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
}

Il est compétitif en termes d'utilisation de l'espace tout en permettant d'ajouter du contexte aux erreurs.

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

Avec essai

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))
    // ...
}

Avec ça

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) }
    // ...
}

Le commentaire d'origine utilisait un hypothétique tryf pour joindre la mise en forme, qui a été supprimée. La meilleure façon d'ajouter tous les contextes distincts n'est pas claire, et peut-être try ne serait même pas applicable.

@ cpuguy83
Pour moi, c'est plus lisible avec try . Dans cet exemple, je lis "ouvrir un fichier, lire tous les octets, envoyer des données". Avec la gestion des erreurs régulière, je lisais "ouvrez un fichier, vérifiez s'il y a eu une erreur, la gestion des erreurs le fait, puis lisez tous les octets, vérifiez maintenant si quelque chose s'est passé ..." Je sais que vous pouvez parcourir le err != nil s, mais pour moi try c'est juste plus facile parce que quand je le vois je connais tout de suite le comportement : renvoie if err != nil. Si vous avez une succursale, je dois voir ce qu'elle fait. Cela pourrait faire n'importe quoi.

Je dirais également qu'un gestionnaire d'erreur différé ici ne serait pas bon, sauf pour simplement envelopper l'erreur avec un nouveau message

Je suis sûr qu'il y a d'autres choses que vous pouvez faire dans le report, mais quoi qu'il en soit, try est de toute façon pour le cas général simple. Chaque fois que vous voulez faire quelque chose de plus, il y a toujours une bonne gestion des erreurs Go. Cela ne va pas disparaître.

@zeebo Oui, je suis dedans.
L'article de @kungfusheep utilisait une vérification d'erreur sur une ligne comme celle-ci et j'ai été excité de l'essayer. Puis dès que j'ai sauvegardé, gofmt l'a étendu en trois lignes, ce qui était triste. De nombreuses fonctions de la stdlib sont définies sur une ligne comme celle-ci, donc cela m'a surpris que gofmt élargisse cela.

@qrpnxz

Il se trouve que je lis beaucoup de code go. L'une des meilleures choses à propos du langage est la facilité avec laquelle la plupart des codes suivent un style particulier (merci gofmt).
Je ne veux pas lire un tas de code enveloppé dans try(f()) .
Cela signifie qu'il y aura soit une divergence dans le style/la pratique du code, soit des linters comme "oh, vous auriez dû utiliser try() ici" (ce que je n'aime même pas, ce qui est le but de moi et d'autres commentant sur cette proposition).

Ce n'est pas objectivement mieux que if err != nil { return err } , juste moins à taper.

Une dernière chose:

Si vous lisiez la proposition, vous verriez que rien ne vous empêche de

Pouvons-nous s'il vous plaît nous abstenir d'un tel langage? Bien sûr, j'ai lu la proposition. Il se trouve que je l'ai lu hier soir, puis que j'ai commenté ce matin après y avoir réfléchi et que je n'ai pas expliqué la minutie de ce que j'avais l'intention.
C'est un ton incroyablement contradictoire.

@ cpuguy83
Mon méchant processeur. Je ne voulais pas dire ça comme ça.

Et je suppose que vous devez souligner que le code qui utilise try sera assez différent du code qui ne le fait pas, donc je peux imaginer que cela affecterait l'expérience d'analyse de ce code, mais je ne peux pas être totalement d'accord que différent signifie pire dans ce cas, même si je comprends que vous ne l'aimez pas personnellement, tout comme je l'aime personnellement. Beaucoup de choses en Go sont ainsi. Quant à ce que les linters vous disent de faire, c'est une tout autre affaire, je pense.

Bien sûr, ce n'est pas objectivement mieux. J'exprimais que c'était plus lisible de cette façon pour moi . J'ai soigneusement formulé cela.

Encore une fois, désolé de sonner ainsi. Bien que ce soit un argument, je ne voulais pas vous contrarier.

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

Personne ne va vous faire essayer.

Ignorant le désinvolture, je pense que c'est une façon assez simple de rejeter une critique de conception.

Bien sûr, je n'ai pas à l'utiliser. Mais n'importe qui avec qui j'écris du code pourrait l'utiliser et me forcer à essayer de déchiffrer try(try(try(to()).parse().this)).easily()) . C'est comme dire

Personne ne va vous faire utiliser l'interface vide{}.

Quoi qu'il en soit, Go est assez strict en matière de simplicité : gofmt donne à tout le code le même aspect. Le chemin heureux reste à gauche et tout ce qui pourrait être coûteux ou surprenant est explicite . try tel qu'il est proposé est un virage à 180 degrés par rapport à cela. Simplicité != concis.

À tout le moins try devrait être un mot-clé avec des lvalues.

Ce n'est pas _objectivement_ meilleur que if err != nil { return err } , juste moins à taper.

Il y a une différence objective entre les deux : try(Foo()) est une expression. Pour certains, cette différence est un inconvénient (la critique try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). Pour d'autres, cette différence est un avantage pour la même raison. Toujours pas objectivement meilleur ou pire - mais je ne pense pas non plus que la différence devrait être balayée sous le tapis et prétendre que c'est "juste moins à taper" ne rend pas justice à la proposition.

@elagergren-spideroak difficile de dire que try est ennuyeux à voir d'un seul souffle, puis de dire que ce n'est pas explicite dans le suivant. Tu dois en choisir un.

il est courant de voir d'abord les arguments de fonction placés dans des variables temporaires. Je suis sûr qu'il serait plus courant de voir

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

que votre exemple.

try ne rien faire est le chemin le plus heureux, donc cela ressemble à ce que nous attendions. Dans le chemin malheureux, il ne fait que revenir. Voir qu'il y a un try est suffisant pour recueillir cette information. Il n'y a rien de cher à revenir d'une fonction non plus, donc d'après cette description, je ne pense pas que try fasse un 180

@josharian Concernant votre commentaire dans https://github.com/golang/go/issues/32437#issuecomment -498941854 , je ne pense pas qu'il y ait une erreur d'évaluation précoce ici.

différer fmt.HandleErrorf(&err, "foobar : %v", err)

La valeur non modifiée de err est passée à HandleErrorf , et un pointeur vers err est passé. Nous vérifions si err est nil (en utilisant le pointeur). Sinon, nous formatons la chaîne en utilisant la valeur non modifiée de err . Ensuite, nous définissons err sur la valeur d'erreur formatée, à l'aide du pointeur.

@Merovius La proposition n'est en réalité qu'une macro de sucre de syntaxe, donc cela finira par concerner ce que les gens pensent être plus beau ou causer le moins de problèmes. Si vous pensez que non, veuillez m'expliquer. C'est pourquoi je suis pour, personnellement. C'est un bel ajout sans ajouter de mots-clés de mon point de vue.

@ianlancetaylor , je pense que @josharian a raison : la valeur "non modifiée" de err est la valeur au moment où le defer est poussé sur la pile, pas la valeur (vraisemblablement prévue) de err défini par try avant de revenir.

L'autre problème que j'ai avec try est qu'il est tellement plus facile pour les gens de vider plus de logique dans une seule ligne. C'est mon problème majeur avec la plupart des autres langages, c'est qu'ils permettent de mettre très facilement 5 expressions sur une seule ligne, et je ne veux pas que ça marche.

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

^^ même c'est carrément horrible. La première ligne, je dois sauter d'avant en arrière en faisant correspondre les parenthèses dans ma tête. Même la deuxième ligne qui est en fait assez simple... est vraiment difficile à lire.
Les fonctions imbriquées sont difficiles à lire.

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

^^ C'est tellement plus facile et meilleur IMO. C'est hyper simple et clair. oui, c'est beaucoup plus de lignes de code, je m'en fous. C'est très évident.

@bcmills @josharian Ah, bien sûr, merci. Il faudrait donc

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

Pas si cool. Peut-être que fmt.HandleErrorf devrait implicitement passer la valeur d'erreur comme dernier argument après tout.

Cette question a suscité beaucoup de commentaires très rapidement, et bon nombre d'entre eux me semblent répéter des commentaires qui ont déjà été faits. Bien sûr, n'hésitez pas à commenter, mais je voudrais gentiment suggérer que si vous voulez reformuler un point qui a déjà été fait, que vous le fassiez en utilisant les emojis de GitHub, plutôt qu'en répétant le point. Merci.

@ianlancetaylor si fmt.HandleErrorf envoie err comme premier argument après le format, l'implémentation sera plus agréable et l'utilisateur pourra toujours le référencer par %[1]v .

@natefinch Absolument d'accord.

Je me demande si une approche de style rouille serait plus acceptable?
Notez que ce n'est pas une proposition juste en y réfléchissant...

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

En fin de compte, je pense que c'est plus agréable, mais (pourrait utiliser un ! ou autre chose aussi...), mais ne résout toujours pas bien le problème de la gestion des erreurs.

bien sûr, la rouille a aussi try() peu près comme ça, mais... l'autre style de rouille.

Ce n'est pas _objectivement_ meilleur que if err != nil { return err } , juste moins à taper.

Il y a une différence objective entre les deux : try(Foo()) est une expression. Pour certains, cette différence est un inconvénient (la critique try(strconv.Atoi(x))+try(strconv.Atoi(y)) ). Pour d'autres, cette différence est un avantage pour la même raison. Toujours pas objectivement meilleur ou pire - mais je ne pense pas non plus que la différence devrait être balayée sous le tapis et prétendre que c'est "juste moins à taper" ne rend pas justice à la proposition.

C'est l'une des principales raisons pour lesquelles j'aime cette syntaxe ; cela me permet d'utiliser une fonction de retour d'erreur dans le cadre d'une expression plus large sans avoir à nommer tous les résultats intermédiaires. Dans certaines situations, les nommer est facile, mais dans d'autres, il n'y a pas de nom particulièrement significatif ou non redondant à leur donner, auquel cas je préfère ne pas leur donner de nom du tout.

@MrTravisB

Exactement mon propos. Cette proposition tente de résoudre un cas d'utilisation singulier plutôt que de fournir un outil pour résoudre le problème plus large de la gestion des erreurs. Je pense que la question fondamentale est exactement ce que vous avez souligné.

Qu'est-ce que j'ai dit précisément qui correspond exactement à votre point de vue ? Il me semble plutôt que vous avez fondamentalement mal compris mon propos si vous pensez que nous sommes d'accord.

À mon avis et par expérience, ce cas d'utilisation est une petite minorité et ne justifie pas une syntaxe abrégée.

Dans la source Go, il y a des milliers de cas qui pourraient être traités par try prêts à l'emploi même s'il n'y avait aucun moyen d'ajouter du contexte aux erreurs. Si mineur, c'est toujours une cause fréquente de plainte.

En outre, l'approche consistant à utiliser le report pour gérer les erreurs présente des problèmes dans la mesure où elle suppose que vous souhaitez gérer toutes les erreurs possibles de la même manière. les instructions différées ne peuvent pas être annulées.

De même, l'approche consistant à utiliser + pour gérer l'arithmétique suppose que vous ne voulez pas soustraire, donc vous ne le faites pas si vous ne le faites pas. La question intéressante est de savoir si le contexte d'erreur à l'échelle du bloc représente au moins un modèle commun.

Que se passe-t-il si je veux une gestion des erreurs différente pour les erreurs qui pourraient être renvoyées par foo() vs foo2()

Encore une fois, vous n'utilisez pas try . Ensuite, vous ne gagnez rien de try , mais vous ne perdez rien non plus.

@ cpuguy83

Je me demande si une approche de style rouille serait plus acceptable?

La proposition présente un argument contre cela.

À ce stade, je pense qu'avoir try{}catch{} est plus lisible :upside_down_face:

1. L'utilisation d'importations nommées pour contourner les cas d'angle defer n'est pas seulement horrible pour des choses comme godoc, mais surtout c'est très sujet aux erreurs. Je m'en fous, je peux envelopper le tout avec un autre func() pour contourner le problème, c'est juste plus de choses que je dois garder à l'esprit, je pense que cela encourage une "mauvaise pratique".

2. Personne ne va vous faire essayer.

   Cela ne veut pas dire que c'est une bonne solution, je souligne que l'idée actuelle a un défaut dans la conception et je demande qu'elle soit traitée d'une manière moins sujette aux erreurs.

3. Je pense que des exemples comme try(try(try(to()).parse().this)).easily()) sont irréalistes, cela pourrait déjà être fait avec d'autres fonctions et je pense qu'il serait juste que ceux qui examinent le code demandent qu'il soit divisé.

4. Que se passe-t-il si j'ai 3 emplacements qui peuvent générer des erreurs et que je souhaite envelopper chaque emplacement séparément ? try() rend cela très difficile, en fait try() décourage déjà les erreurs d'emballage compte tenu de sa difficulté, mais voici un exemple de ce que je veux dire :

   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. Encore une fois, vous n'utilisez pas try . Ensuite, vous ne gagnez rien de try , mais vous ne perdez rien non plus.

   Disons que c'est une bonne pratique d'envelopper les erreurs avec un contexte utile, try() serait considéré comme une mauvaise pratique car cela n'ajoute aucun contexte. Cela signifie que try() est une fonctionnalité que personne ne veut utiliser et qui devient une fonctionnalité si rarement utilisée qu'elle n'a peut-être pas existé.

   Au lieu de simplement dire "eh bien, si vous ne l'aimez pas, ne l'utilisez pas et taisez-vous" (c'est ainsi qu'il se lit), je pense qu'il serait préférable d'essayer de résoudre ce que beaucoup d'utilisateurs considèrent comme un défaut Dans le design. Pouvons-nous discuter à la place de ce qui pourrait être modifié par rapport à la conception proposée afin que notre préoccupation soit mieux gérée ?

@boomlinde Le point sur lequel nous sommes d'accord est que cette proposition tente de résoudre un cas d'utilisation mineur et le fait que "si vous n'en avez pas besoin, ne l'utilisez pas" est l'argument principal pour cela. Comme @elagergren-spideroak l'a déclaré, cet argument ne fonctionne pas car même si je ne veux pas l'utiliser, d'autres le feront, ce qui m'oblige à l'utiliser. Selon la logique de votre argument, Go devrait également avoir une déclaration ternaire. Et si vous n'aimez pas les déclarations ternaires, ne les utilisez pas.

Avis de non-responsabilité - Je pense que Go devrait avoir une déclaration ternaire, mais étant donné que l'approche de Go en matière de fonctionnalités linguistiques consiste à ne pas introduire de fonctionnalités susceptibles de rendre le code plus difficile à lire, il ne devrait pas en être ainsi.

Une autre chose me vient à l'esprit : je vois beaucoup de critiques basées sur l'idée qu'avoir try pourrait encourager les développeurs à gérer les erreurs avec négligence. Mais à mon avis, c'est plutôt vrai du langage actuel ; le passe-partout de gestion des erreurs est suffisamment ennuyeux pour inciter à avaler ou à ignorer certaines erreurs pour les éviter. Par exemple, j'ai écrit plusieurs fois des choses comme ça :

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

afin de pouvoir écrire if exists(...) { ... } , même si ce code ignore silencieusement certaines erreurs possibles. Si j'avais try , je ne prendrais probablement pas la peine de le faire et je retournerais simplement (bool, error) .

Étant chaotique ici, je vais lancer l'idée d'ajouter une deuxième fonction intégrée appelée catch qui recevra une fonction qui prend une erreur et renvoie une erreur écrasée, puis si un catch est appelé, il écraserait le gestionnaire. par exemple:

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

Désormais, cette fonction intégrée sera également une fonction de type macro qui gérera la prochaine erreur renvoyée par try comme ceci :

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>"
}

C'est bien parce que je peux envelopper les erreurs sans defer qui peuvent être sujettes aux erreurs à moins que nous n'utilisions des valeurs de retour nommées ou envelopper avec une autre fonction, c'est aussi bien parce que defer ajouterait le même gestionnaire d'erreurs pour toutes les erreurs même si je veux en gérer 2 différemment. Vous pouvez également l'utiliser comme bon vous semble, par exemple :

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
}

Et toujours d'humeur chaotique (pour vous aider à comprendre) Si vous n'aimez pas catch , vous n'êtes pas obligé de l'utiliser.

Maintenant... Je ne parle pas vraiment de la dernière phrase, mais j'ai l'impression que ce n'est pas utile pour la discussion, très agressif IMO.
Pourtant, si nous suivions cette voie, je pense que nous pourrions aussi bien avoir try{}catch(error err){} la place :stuck_out_tongue:

Voir aussi #27519 - le modèle d'erreur #id/catch

Personne ne va vous faire essayer.

Ignorant le désinvolture, je pense que c'est une façon assez simple de rejeter une critique de conception.

Désolé, le glib n'était pas mon intention.

Ce que j'essaie de dire, c'est que try n'est pas censé être une solution à 100 %. Il existe divers paradigmes de gestion des erreurs qui ne sont pas bien gérés par try . Par exemple, si vous devez ajouter un contexte dépendant du site d'appel à l'erreur. Vous pouvez toujours recourir à if err != nil { pour gérer ces cas plus compliqués.

C'est certainement un argument valable que try ne peut pas gérer X, pour diverses instances de X. Mais souvent, gérer le cas X signifie rendre le mécanisme plus compliqué. Il y a un compromis ici, manipulant X d'une part mais compliquant le mécanisme pour tout le reste. Ce que nous faisons dépend de la fréquence de X et de la complexité nécessaire pour gérer X.

Donc par "personne ne va te faire utiliser try", je veux dire que je pense que l'exemple en question est dans les 10%, pas dans les 90%. Cette affirmation est certainement sujette à débat, et je suis heureux d'entendre des contre-arguments. Mais finalement, nous devrons tracer une ligne quelque part et dire "ouais, try ne gérera pas ce cas. Vous devrez utiliser la gestion des erreurs à l'ancienne. Désolé.".

Ce n'est pas "essayer ne peut pas gérer ce cas spécifique de gestion des erreurs" qui est le problème, c'est "essayer vous encourage à ne pas envelopper vos erreurs". L'idée check-handle vous obligeait à écrire une instruction de retour, donc écrire un emballage d'erreur était assez trivial.

Dans cette proposition, vous devez utiliser un retour nommé avec un defer , ce qui n'est pas intuitif et semble très hacky.

L'idée check-handle vous obligeait à écrire une instruction de retour, donc écrire un emballage d'erreur était assez trivial.

Ce n'est pas vrai - dans le brouillon de conception, chaque fonction qui renvoie une erreur a un gestionnaire par défaut qui renvoie simplement l'erreur.

S'appuyant sur le point espiègle de @Goodwine , vous n'avez pas vraiment besoin de fonctions séparées comme HandleErrorf si vous avez une seule fonction de pont comme

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

que vous utiliseriez comme

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

Vous pourriez faire handler lui-même un semi-magique intégré comme try .

Si c'est magique, il pourrait prendre implicitement son premier argument, lui permettant d'être utilisé même dans des fonctions qui ne nomment pas leur retour error , éliminant l'un des aspects les moins chanceux de la proposition actuelle tout en la rendant moins pointilleux et sujet aux erreurs pour décorer les erreurs. Bien sûr, cela ne réduit pas beaucoup l'exemple précédent :

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

Si c'était magique de cette manière, il faudrait que ce soit une erreur de compilation s'il était utilisé n'importe où sauf comme argument de defer . Vous pourriez aller plus loin et le faire différer implicitement, mais defer handler se lit assez bien.

Puisqu'il utilise defer , il pourrait appeler sa fonction handle chaque fois qu'une erreur non nulle est renvoyée, ce qui le rend utile même sans try puisque vous pouvez ajouter un

defer handler(wrapErrWithPackageName)

en haut à fmt.Errorf("mypkg: %w", err) tout.

Cela vous donne une grande partie de l'ancienne proposition check / handle mais cela fonctionne avec le report naturellement (et explicitement) tout en vous débarrassant de la nécessité, dans la plupart des cas, de nommer explicitement un err retour. Comme try , c'est une macro relativement simple qui (j'imagine) pourrait être entièrement implémentée dans le front-end.

Ce n'est pas vrai - dans le brouillon de conception, chaque fonction qui renvoie une erreur a un gestionnaire par défaut qui renvoie simplement l'erreur.

Mon mauvais, vous avez raison.

Je veux dire que je pense que l'exemple en question est dans les 10%, pas dans les 90%. Cette affirmation est certainement sujette à débat, et je suis heureux d'entendre des contre-arguments. Mais finalement, nous devrons tracer une ligne quelque part et dire "oui, essayer ne traitera pas ce cas. Vous devrez utiliser la gestion des erreurs à l'ancienne. Désolé.".

D'accord, mon opinion est que cette ligne doit être tracée lors de la vérification d'EOF ou similaire, pas lors de l'emballage. Mais peut-être que si les erreurs avaient plus de contexte, cela ne serait plus un problème.

Est-ce try() peut envelopper automatiquement les erreurs avec un contexte utile pour le débogage ? Par exemple, si xerrors devient errors , les erreurs devraient avoir quelque chose qui ressemble à une trace de pile que try() pourrait ajouter, non ? Si oui, cela suffirait peut-être 🤔

Si les objectifs sont (lire https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md) :

• éliminer le passe-partout
• changements de langue minimes
• couvrant "les scénarios les plus courants"
• ajoutant très peu de complexité au langage

Je prendrais la suggestion, donnez-lui un angle et autorisez la migration de code "par petites étapes" pour tous les milliards de lignes de code qui existent.

au lieu de la suggestion :

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
}

Nous pouvons:

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
}

Que gagnerions-nous ?
twoStringsErr peut être intégré à printSum, ou un gestionnaire général qui sait comment capturer les erreurs (dans ce cas avec 2 paramètres de chaîne) - donc si j'ai les mêmes signatures func répétitives utilisées dans plusieurs de mes fonctions, je n'ai pas besoin de réécrire le gestionnaire chaque temps
de la même manière, je peux avoir le type ErrHandler étendu de la manière suivante :

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

}

ou

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

}

ou

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

}

et utilisez ceci tout autour de mon mon 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
}

Ainsi, le besoin réel serait de développer un déclencheur lorsque err.Error est défini sur not nil
En utilisant cette méthode, nous pouvons également :

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

Ce qui dirait à la fonction appelante de continuer au lieu de revenir

Et utilisez différents gestionnaires d'erreurs dans la même fonction :

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
}

etc.

Revoir les objectifs

• éliminer le passe-partout - c'est fait
• changements de langage minimaux - terminé
• couvrant les "scénarios les plus courants" - plus que l'OMI suggérée
• ajoutant très peu de complexité à la langue - sone
  Plus - migration de code plus facile à partir de

x, err := strconv.Atoi(a)

pour

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

et en fait - une meilleure lisibilité (IMO, encore une fois)

@guybrand vous êtes le dernier adhérent à ce thème récurrent (que j'aime).

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

@guybrand Cela semble être une proposition entièrement différente; Je pense que vous devriez le classer comme son propre problème afin que celui-ci puisse se concentrer sur la discussion de la proposition de @griesemer .

@natefinch est d'accord. Je pense que cela vise davantage à améliorer l'expérience lors de l'écriture de Go au lieu d'optimiser la lecture. Je me demande si des macros ou des extraits IDE pourraient résoudre le problème sans que cela devienne une caractéristique du langage.

@Bon vin

Disons que c'est une bonne pratique d'envelopper les erreurs avec un contexte utile, try() serait considéré comme une mauvaise pratique car cela n'ajoute aucun contexte. Cela signifie que try() est une fonctionnalité que personne ne veut utiliser et qui devient une fonctionnalité si rarement utilisée qu'elle n'a peut-être pas existé.

Comme indiqué dans la proposition (et illustré par un exemple), try ne vous empêche pas fondamentalement d'ajouter du contexte. Je dirais que la façon dont c'est proposé, ajouter du contexte aux erreurs est tout à fait orthogonale. Ceci est spécifiquement abordé dans la FAQ de la proposition.

Je reconnais que try ne sera pas utile si dans une seule fonction s'il existe une multitude de contextes différents que vous souhaitez ajouter à différentes erreurs d'appels de fonction. Cependant, je pense également que quelque chose dans la veine générale de HandleErrorf couvre un large domaine d'utilisation, car il n'est pas inhabituel d'ajouter uniquement un contexte à l'échelle de la fonction aux erreurs.

Au lieu de simplement dire "eh bien, si vous ne l'aimez pas, ne l'utilisez pas et taisez-vous" (c'est ainsi qu'il se lit), je pense qu'il serait préférable d'essayer de résoudre ce que beaucoup d'utilisateurs considèrent comme un défaut Dans le design.

Si c'est ainsi qu'il se lit, je m'en excuse. Mon propos n'est pas que vous devriez prétendre qu'il n'existe pas si vous ne l'aimez pas. C'est qu'il est évident qu'il y a des cas dans lesquels try seraient inutiles et que vous ne devriez pas l'utiliser dans de tels cas, ce qui, pour cette proposition, je crois, établit un bon équilibre entre KISS et l'utilité générale. Je ne pensais pas avoir été flou sur ce point.

Merci à tous pour les commentaires prolifiques jusqu'à présent ; c'est très instructif.
Voici ma tentative de résumé initial, pour avoir une meilleure idée des commentaires. Toutes mes excuses à l'avance pour tous ceux que j'ai manqués ou mal représentés ; J'espère que j'ai bien compris l'essentiel.

0) Du côté positif, @rasky , @adg , @eandre , @dpinela et d'autres ont explicitement exprimé leur bonheur face à la simplification du code fournie par try .

1) La préoccupation la plus importante semble être que try n'encourage pas un bon style de gestion des erreurs, mais favorise plutôt la "sortie rapide". ( @agnivade , @peterbourgon , @politician , @a8m , @eandre , @prologic , @kungfusheep , @cpuguy , et d'autres ont exprimé leur inquiétude à ce sujet.)

2) Beaucoup de gens n'aiment pas l'idée d'une fonction intégrée ou la syntaxe de fonction qui l'accompagne car elle cache un return . Il serait préférable d'utiliser un mot-clé. ( @sheerun , @Redundancy , @dolmen , @komuw , @RobertGrantEllis , @elagergren-spideroak). try peut également être facilement ignoré (@peterbourgon), notamment parce qu'il peut apparaître dans des expressions arbitrairement imbriquées. @natefinch craint que try ne rende "trop ​​facile d'en vider trop sur une seule ligne", ce que nous essayons généralement d'éviter dans Go. De plus, le support IDE pour mettre l'accent sur try peut ne pas être suffisant (@dominikh); try doit "être autonome".

3) Pour certains, le statu quo des déclarations explicites if n'est pas un problème, ils en sont satisfaits ( @bitfield , @marwan-at-work, @natefinch). Il vaut mieux n'avoir qu'une seule façon de faire les choses (@gbbr); et les instructions if explicites sont meilleures que return implicites ( @DavexPro , @hmage , @prologic , @natefinch).
Dans le même ordre d'idées, @mattn est préoccupé par la "liaison implicite" du résultat d'erreur à try - la connexion n'est pas explicitement visible dans le code.

4) L'utilisation try rendra plus difficile le débogage du code ; par exemple, il peut être nécessaire de réécrire une expression try dans une instruction if juste pour que les instructions de débogage puissent être insérées ( @deanveloper , @typeless , @networkimprov , autres).

5) L'utilisation de retours nommés ( @buchanae , @adg) suscite des inquiétudes.

Plusieurs personnes ont fourni des suggestions pour améliorer ou modifier la proposition :

6) Certains ont repris l'idée d'un gestionnaire d'erreurs facultatif (@beoran) ou d'une chaîne de format fournie à try ( @unexge , @a8m , @eandre , @gotwarlost) pour encourager une bonne gestion des erreurs.

7) @pierrec a suggéré que gofmt pourrait formater les expressions try manière appropriée pour les rendre plus visibles.
Alternativement, on pourrait rendre le code existant plus compact en permettant gofmt de formater les instructions if vérifiant les erreurs sur une ligne (@zeebo).

8) @marwan-at-work soutient que try déplace simplement la gestion des erreurs des instructions $#$ if $#$ vers les expressions try . Au lieu de cela, si nous voulons réellement résoudre le problème, Go devrait "posséder" la gestion des erreurs en la rendant vraiment implicite. L'objectif devrait être de rendre la gestion des erreurs (correcte) plus simple et les développeurs plus productifs (@cpuguy).

9) Enfin, certaines personnes n'aiment pas le nom try ( @beoran , @HiImJC , @dolmen) ou préféreraient un symbole tel que ? ( @twisted1919 , @leaxoy , autres) .

Quelques commentaires sur ces commentaires (numérotés en conséquence) :

0) Merci pour les commentaires positifs ! :-)

1) Il serait bon d'en savoir plus sur ce souci. Le style de codage actuel utilisant les instructions if pour tester les erreurs est à peu près aussi explicite que possible. Il est très facile d'ajouter des informations supplémentaires à une erreur, sur une base individuelle (pour chaque if ). Souvent, il est logique de gérer toutes les erreurs détectées dans une fonction de manière uniforme, ce qui peut être fait avec un defer - c'est déjà possible maintenant. C'est le fait que nous avons déjà tous les outils pour une bonne gestion des erreurs dans le langage, et le problème d'une construction de gestionnaire non orthogonale à defer , qui nous a conduit à laisser de côté un nouveau mécanisme uniquement pour augmenter les erreurs .

2) Il y a bien sûr la possibilité d'utiliser un mot-clé ou une syntaxe spéciale au lieu d'un intégré. Un nouveau mot clé ne sera pas rétrocompatible. Un nouvel opérateur pourrait, mais semble encore moins visible. La proposition détaillée discute longuement des différents avantages et inconvénients. Mais peut-être méconnaît-on cela.

3) La raison de cette proposition est que la gestion des erreurs (en particulier le code passe-partout associé) a été mentionnée comme un problème important dans Go (à côté du manque de génériques) par la communauté Go. Cette proposition répond directement à la préoccupation passe-partout. Il ne fait pas plus que résoudre le cas le plus élémentaire car tout cas plus complexe est mieux traité avec ce que nous avons déjà. Ainsi, alors qu'un bon nombre de personnes sont satisfaites du statu quo, il existe un contingent (probablement) tout aussi important de personnes qui aimeraient une approche plus rationalisée telle que try , sachant bien que c'est "juste" sucre syntaxique.

4) Le point de débogage est une préoccupation valable. S'il est nécessaire d'ajouter du code entre la détection d'une erreur et un return , devoir réécrire une expression try dans une instruction if peut être ennuyeux.

5) Valeurs de retour nommées : Le document détaillé en parle longuement. Si c'est la principale préoccupation de cette proposition, alors nous sommes dans une bonne position, je pense.

6) Argument optionnel du gestionnaire à try : Le document détaillé en parle également. Voir la section sur les itérations de conception.

7) Utiliser gofmt pour formater les expressions try manière à ce qu'elles soient plus visibles serait certainement une option. Mais cela enlèverait certains des avantages de try lorsqu'il est utilisé dans une expression.

8) Nous avons envisagé d'examiner le problème du point de vue de la gestion des erreurs ( handle ) plutôt que du point de vue du test des erreurs ( try ). Plus précisément, nous avons brièvement envisagé d'introduire uniquement la notion de gestionnaire d'erreurs (similaire au projet de conception original présenté à la Gophercon de l'année dernière). L'idée était que si (et seulement si) un gestionnaire est déclaré, dans les affectations à plusieurs valeurs où la dernière valeur est de type error , cette valeur peut simplement être laissée de côté dans une affectation. Le compilateur vérifierait implicitement s'il est non-nil, et si c'est le cas, branchez-le au gestionnaire. Cela ferait disparaître complètement la gestion explicite des erreurs et encouragerait tout le monde à écrire un gestionnaire à la place. Cela semblait une approche extrême car elle serait complètement implicite - le fait qu'une vérification se produise serait invisible.

9) Puis-je suggérer que nous ne perdons pas le nom à vélo à ce stade. Une fois que toutes les autres préoccupations sont réglées, il est préférable d'affiner le nom.

Cela ne veut pas dire que les préoccupations ne sont pas fondées - les réponses ci-dessus indiquent simplement notre pensée actuelle. À l'avenir, il serait bon de commenter les nouvelles préoccupations (ou de nouvelles preuves à l'appui de ces préoccupations) - le simple fait de répéter ce qui a déjà été dit ne nous fournit pas plus d'informations.

Et enfin, il semble que tous ceux qui commentent le problème n'ont pas lu la doc détaillée. Veuillez le faire avant de commenter pour éviter de répéter ce qui a déjà été dit. Merci.

Ceci n'est pas un commentaire sur la proposition, mais un rapport de faute de frappe. Il n'a pas été corrigé depuis la publication de la proposition complète, alors j'ai pensé le mentionner :

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

devrait être:

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

Cela vaudrait-il la peine d'analyser le code Go librement disponible pour les instructions de vérification des erreurs afin d'essayer de déterminer si la plupart des vérifications d'erreurs sont vraiment répétitives ou si, dans la plupart des cas, plusieurs vérifications au sein de la même fonction ajoutent des informations contextuelles différentes ? La proposition aurait beaucoup de sens pour le premier cas, mais n'aiderait pas le second. Dans ce dernier cas, les utilisateurs continueront d'utiliser if err != nil ou renonceront à ajouter un contexte supplémentaire, utiliseront try() et auront recours à l'ajout d'un contexte d'erreur commun par fonction, ce qui, selon l'OMI, serait nuisible. Avec les fonctionnalités de valeurs d'erreur à venir, je pense que nous nous attendons à ce que les gens enveloppent plus souvent les erreurs avec plus d'informations. J'ai probablement mal compris la proposition, mais AFAIU, cela aide à réduire le passe-partout uniquement lorsque toutes les erreurs d'une seule fonction doivent être enveloppées exactement d'une manière et n'aide pas si une fonction traite cinq erreurs qui pourraient devoir être enveloppées différemment. Je ne sais pas à quel point de tels cas sont courants dans la nature (assez courants dans la plupart de mes projets), mais je crains que try() n'encourage les gens à utiliser des wrappers communs par fonction même s'il serait logique d'envelopper différentes erreurs différemment.

Juste un commentaire rapide soutenu par les données d'un petit jeu d'échantillons :

Nous proposons une nouvelle fonction intégrée appelée try, conçue spécifiquement pour éliminer le passe-partout si les instructions généralement associées à la gestion des erreurs dans Go

Si c'est le problème principal résolu par cette proposition, je trouve que ce "type standard" ne représente qu'environ 1,4 % de mon code sur des dizaines de projets open source accessibles au public totalisant environ 60 000 SLOC.

Curieux de savoir si quelqu'un d'autre a des statistiques similaires ?

Sur une base de code beaucoup plus grande comme Go elle-même totalisant environ ~ 1,6 million de SLOC, cela équivaut à environ 0,5 % de la base de code ayant des lignes comme if err != nil .

Est-ce vraiment le problème le plus impactant à résoudre avec Go 2 ?

Merci beaucoup @griesemer d'avoir pris le temps de passer en revue les idées de chacun et d'avoir explicitement fourni des réflexions. Je pense que cela aide vraiment à donner l'impression que la communauté est entendue dans le processus.

1. @pierrec a suggéré que gofmt pourrait formater les expressions try de manière appropriée pour les rendre plus visibles.
   Alternativement, on pourrait rendre le code existant plus compact en permettant à gofmt de formater les instructions if vérifiant les erreurs sur une ligne (@zeebo).

1. Utiliser gofmt pour formater les expressions try manière à ce qu'elles soient plus visibles serait certainement une option. Mais cela enlèverait certains des avantages de try lorsqu'il est utilisé dans une expression.

Ce sont des réflexions précieuses sur l'exigence gofmt pour formater try , mais je suis intéressé s'il y a des réflexions en particulier sur gofmt permettant la vérification de l'instruction if l'erreur d'être une ligne. La proposition a été regroupée avec un formatage de try , mais je pense que c'est une chose complètement orthogonale. Merci.

@griesemer merci pour le travail incroyable qui a parcouru tous les commentaires et répondu à la plupart sinon à tous les commentaires 🎉

Une chose qui n'a pas été abordée dans vos commentaires était l'idée d'utiliser la partie outils/vérification du langage Go pour améliorer l'expérience de gestion des erreurs, plutôt que de mettre à jour la syntaxe Go.

Par exemple, avec l'arrivée du nouveau LSP ( gopls ), cela semble être un endroit parfait pour analyser la signature d'une fonction et prendre en charge le passe-partout de gestion des erreurs pour le développeur, avec un emballage et une vérification appropriés également.

@griesemer Je suis sûr que ce n'est pas bien pensé, mais j'ai essayé de modifier votre suggestion plus près de quelque chose avec laquelle je serais à l'aise ici : https://www.reddit.com/r/golang/comments/bwvyhe /proposal_a_builtin_go_error_check_function_try/eq22bqa?utm_source=share&utm_medium=web2x

@zeebo Il serait facile de faire le format $ gofmt if err != nil { return ...., err } sur une seule ligne. Vraisemblablement, ce ne serait que pour ce type spécifique de modèle if , pas toutes les instructions "courtes" if ?

Dans le même ordre d'idées, on craignait que try ne soit invisible car il se trouve sur la même ligne que la logique métier. Nous avons toutes ces options :

Style actuel :

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

Une ligne if :

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

try sur une ligne distincte (!) :

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

try tel que proposé :

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

La première et la dernière ligne me semblent les plus claires, surtout une fois que l'on est habitué à reconnaître try comme ce qu'il est. Avec la dernière ligne, une erreur est explicitement vérifiée, mais comme ce n'est (généralement) pas l'action principale, elle est un peu plus en arrière-plan.

@marwan-at-work Je ne suis pas sûr de ce que vous proposez que les outils fassent pour vous. Suggérez-vous qu'ils cachent la gestion des erreurs d'une manière ou d'une autre ?

@dpinela

@guybrand Cela semble être une proposition entièrement différente; Je pense que vous devriez le classer comme son propre problème afin que celui-ci puisse se concentrer sur la discussion de la proposition de @griesemer .

IMO ma proposition ne diffère que par la syntaxe, ce qui signifie :

• Les objectifs sont similaires dans leur contenu et leur priorité.
• L'idée de capturer chaque erreur dans sa propre ligne et en conséquence (sinon nil) de quitter la fonction tout en passant par une fonction de gestionnaire est similaire (pseudo asm - c'est un "jnz" et un "appel").
• Cela signifie même que le nombre de lignes dans un corps de fonction (sans le report) et le flux se ressembleraient exactement (et par conséquent, AST se révélerait probablement le même également)

donc le diff principal est de savoir si nous enveloppons l'appel de fonction d'origine avec try(func()) qui analyserait toujours la dernière var pour jnz l'appel ou utiliserait la valeur de retour réelle pour le faire.

Je sais que ça a l'air différent, mais en fait très similaire dans son concept.
D'un autre côté - si vous prenez l'essai habituel .... catch dans de nombreux langages de type c - ce serait une implémentation très différente, une lisibilité différente, etc.

Je pense cependant sérieusement à écrire une proposition, merci pour l'idée.

@griesemer

Je ne suis pas sûr de ce que vous proposez que les outils font pour vous. Suggérez-vous qu'ils cachent la gestion des erreurs d'une manière ou d'une autre ?

Bien au contraire : je suggère que gopls puisse éventuellement écrire le passe-partout de gestion des erreurs pour vous.

Comme vous l'avez mentionné dans votre dernier commentaire :

La raison de cette proposition est que la gestion des erreurs (en particulier le code passe-partout associé) a été mentionnée comme un problème important dans Go (à côté du manque de génériques) par la communauté Go

Ainsi, le cœur du problème est que le programmeur finit par écrire beaucoup de code passe-partout. Il s'agit donc d'écrire, pas de lire. Par conséquent, ma suggestion est la suivante : laissez l'ordinateur (tooling/gopls) écrire pour le programmeur en analysant la signature de la fonction et en plaçant les clauses de gestion des erreurs appropriées.

Par exemple:

// 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
}

Ensuite, l'utilisateur déclenche l'outil, peut-être en enregistrant simplement le fichier (similaire au fonctionnement typique de gofmt/goimports) et gopls regarderait cette fonction, analyserait sa signature de retour et augmenterait le code pour qu'il soit celui-ci :

// 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
}

De cette façon, nous obtenons le meilleur des deux mondes : nous obtenons la lisibilité/l'explicitation du système de gestion des erreurs actuel, et le programmeur n'a écrit aucun passe-partout de gestion des erreurs. Mieux encore, l'utilisateur peut continuer et modifier les blocs de gestion des erreurs plus tard pour adopter un comportement différent : gopls peut comprendre que le bloc existe, et il ne le modifiera pas.

Comment l'outil saurait-il que j'ai l'intention de gérer le err plus tard dans la fonction au lieu de revenir plus tôt ? Bien que rare, mais le code que j'ai écrit néanmoins.

Je m'excuse si cela a déjà été soulevé, mais je n'ai trouvé aucune mention à ce sujet.

try(DoSomething()) se lit bien pour moi et a du sens : le code essaie de faire quelque chose. try(err) , OTOH, se sent un peu décalé, sémantiquement parlant : comment tenter une erreur ? Dans mon esprit, on pourrait _tester_ ou _vérifier_ une erreur, mais _essayer_ une ne semble pas correcte.

Je me rends compte qu'il est important d'autoriser try(err) pour des raisons de cohérence : je suppose que ce serait étrange si try(DoSomething()) fonctionnait, mais pas err := DoSomething(); try(err) . Pourtant, on a l'impression que try(err) semble un peu gênant sur la page. Je ne peux pas penser à d'autres fonctions intégrées qui peuvent être rendues aussi étranges si facilement.

Je n'ai pas de suggestions concrètes à ce sujet, mais je voulais quand même faire ce constat.

@griesemer Merci. En effet, la proposition ne devait être que pour return , mais je soupçonne que permettre à une seule déclaration d'être une seule ligne serait bien. Par exemple, dans un test, on pourrait, sans modification de la bibliothèque de test, avoir

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

La première et la dernière ligne me semblent les plus claires, surtout une fois qu'on a l'habitude de reconnaître l'essai pour ce qu'il est. Avec la dernière ligne, une erreur est explicitement vérifiée, mais comme ce n'est (généralement) pas l'action principale, elle est un peu plus en arrière-plan.

Avec la dernière ligne, une partie du coût est masquée. Si vous voulez annoter l'erreur, ce qui, je crois, est la meilleure pratique souhaitée par la communauté et devrait être encouragée, il faudrait changer la signature de la fonction pour nommer les arguments et espérer qu'un seul defer s'applique à chaque sortie dans le corps de la fonction, sinon try n'a pas de valeur ; peut-être même négatif en raison de sa facilité.

Je n'ai rien de plus à ajouter qui je crois n'ait déjà été dit.

Je n'ai pas vu comment répondre à cette question dans la doc de conception. Que fait ce 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
}

D'après ce que j'ai compris, cela désucrerait

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
}

qui ne parvient pas à compiler car err est masqué lors d'un retour nu. Cela ne compilerait-il pas ? Si tel est le cas, il s'agit d'un échec très subtil et il ne semble pas trop improbable qu'il se produise. Sinon, alors il se passe plus que du sucre.

@marwan-au-travail

Comme vous l'avez mentionné dans votre dernier commentaire :

La raison de cette proposition est que la gestion des erreurs (en particulier le code passe-partout associé) a été mentionnée comme un problème important dans Go (à côté du manque de génériques) par la communauté Go

Ainsi, le cœur du problème est que le programmeur finit par écrire beaucoup de code passe-partout. Il s'agit donc d'écrire, pas de lire.

Je pense que c'est en fait l'inverse - pour moi, le plus gros ennui avec le passe-partout actuel de gestion des erreurs n'est pas tant d'avoir à le taper, mais plutôt comment il disperse le chemin heureux de la fonction verticalement sur l'écran, ce qui le rend plus difficile à comprendre à un coup d'oeil. L'effet est particulièrement prononcé dans le code lourd en E/S, où il y a généralement un bloc de passe-partout entre deux opérations. Même une version simpliste de CopyFile prend environ 20 lignes même si elle n'effectue en réalité que cinq étapes : ouvrir la source, différer la fermeture de la source, ouvrir la destination, copier la source -> destination, fermer la destination.

Un autre problème avec la syntaxe actuelle est que, comme je l'ai noté plus tôt, si vous avez une chaîne d'opérations dont chacune peut renvoyer une erreur, la syntaxe actuelle vous oblige à donner des noms à tous les résultats intermédiaires, même si vous préférez laisser quelques anonymes. Lorsque cela se produit, cela nuit également à la lisibilité car vous devez passer des cycles cérébraux à analyser ces noms, même s'ils ne sont pas très informatifs.

J'aime try sur une ligne séparée.
Et j'espère qu'il pourra spécifier indépendamment la fonction handler .

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 : Les exemples que j'ai donnés sont des traductions 1:1. Le premier (traditionnel if ) n'a pas géré l'erreur, pas plus que les autres. Si le premier a géré l'erreur, et si c'était le seul endroit où une erreur est vérifiée dans une fonction, le premier exemple (utilisant un if ) pourrait être le choix approprié pour écrire le code. S'il y a plusieurs vérifications d'erreurs, qui utilisent toutes la même gestion des erreurs (wrapping), disons parce qu'elles ajoutent toutes des informations sur la fonction actuelle, on peut utiliser une instruction defer pour gérer les erreurs en un seul endroit. En option, on pourrait réécrire les if en try (ou les laisser seuls). S'il y a plusieurs erreurs à vérifier et qu'elles gèrent toutes les erreurs différemment (ce qui peut être un signe que le problème de la fonction est trop large et qu'il peut être nécessaire de le scinder), l'utilisation if est la marche à suivre. Oui, il y a plus d'une façon de faire la même chose, et le bon choix dépend du code ainsi que des goûts personnels. Bien que nous nous efforcions en Go d'avoir "une façon de faire une chose", ce n'est bien sûr déjà pas le cas, en particulier pour les constructions courantes. Par exemple, lorsqu'une séquence if - else - if devient trop longue, parfois un switch peut être plus approprié. Parfois, une déclaration de variable var x int exprime mieux l'intention que x := 0 , et ainsi de suite (bien que cela ne plaise pas à tout le monde).

Concernant votre question sur la "réécriture": Non, il n'y aurait pas d'erreur de compilation. Notez que la réécriture se produit en interne (et peut être plus efficace que ne le suggère le modèle de code), et il n'est pas nécessaire que le compilateur se plaigne d'un retour caché. Dans votre exemple, vous avez déclaré une variable locale err dans une portée imbriquée. try aurait toujours un accès direct à la variable de résultat err , bien sûr. La réécriture pourrait ressembler davantage à ceci sous les couvertures.

[modifié] PS : Une meilleure réponse serait : try n'est pas un retour nu (même si la réécriture y ressemble). Après tout, on donne explicitement à try un argument qui contient (ou est) l'erreur renvoyée si ce n'est pas nil . L'erreur fantôme pour les retours nus est une erreur sur la source (et non la traduction sous-jacente de la source. Le compilateur n'a pas besoin de l'erreur.

Si le type de retour final de la fonction globale n'est pas de type erreur, pouvons-nous paniquer ?

Cela rendra l'intégration plus polyvalente (comme satisfaire ma préoccupation dans # 32219)

@pjebs Cela a été considéré et rejeté. Veuillez lire la documentation de conception détaillée (qui fait explicitement référence à votre problème à ce sujet).

Je tiens également à souligner que try() est traité comme une expression même s'il fonctionne comme une instruction de retour. Oui, je sais que try est une macro intégrée, mais la plupart des utilisateurs l'utiliseront comme une programmation fonctionnelle, je suppose.

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

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

La conception indique que vous avez exploré en utilisant panic au lieu de revenir avec l'erreur.

Je mets en évidence une subtile différence :

Faites exactement ce que votre proposition actuelle indique, à l'exception de la suppression de la restriction selon laquelle la fonction globale doit avoir un type de retour final de type error .

S'il n'a pas de type de retour final de error => panique
Si vous utilisez try pour les déclarations de variables au niveau du package => panique (supprime le besoin de convention MustXXX( ) )

Pour les tests unitaires, un changement de langage modeste.

@mattn , je doute fortement qu'un nombre significatif de personnes écrira du code comme ça.

@pjebs , cette sémantique - paniquez s'il n'y a pas de résultat d'erreur dans la fonction actuelle - est exactement ce dont parle le document de conception dans https://github.com/golang/proposal/blob/master/design/32437-try-builtin. md#discussion.

De plus, dans une tentative de rendre try utile non seulement à l'intérieur des fonctions avec un résultat d'erreur, la sémantique de try dépendait du contexte : si try était utilisé au niveau du package, ou s'il était appelé à l'intérieur d'une fonction sans résultat d'erreur, try paniquerait en rencontrant une erreur. (Soit dit en passant, à cause de cette propriété, la fonction intégrée a été appelée must plutôt que try dans cette proposition.) Avoir try (ou must) se comporter de cette manière sensible au contexte semblait naturel et aussi très utile : cela permettrait l'élimination de de nombreuses fonctions d'assistance must définies par l'utilisateur actuellement utilisées dans les expressions d'initialisation de variables au niveau du package. Cela ouvrirait également la possibilité d'utiliser try dans les tests unitaires via le package de test.

Pourtant, la sensibilité au contexte de try était considérée comme lourde : par exemple, le comportement d'une fonction contenant des appels try pouvait changer silencieusement (de paniquer éventuellement à ne pas paniquer, et vice versa) si un résultat d'erreur était ajouté ou supprimé de la signature. Cela semblait une propriété trop dangereuse. La solution évidente aurait été de diviser la fonctionnalité de try en deux fonctions distinctes, must et try (très similaire à ce qui est suggéré par le problème #31442). Mais cela aurait nécessité deux nouvelles fonctions intégrées, avec seulement un essai directement lié au besoin immédiat d'une meilleure prise en charge de la gestion des erreurs.

@pjebs C'est _exactement_ ce que nous avons considéré dans une proposition précédente (voir doc détaillé, section sur les itérations de conception, 4e paragraphe):

De plus, dans une tentative de rendre try utile non seulement à l'intérieur des fonctions avec un résultat d'erreur, la sémantique de try dépendait du contexte : si try était utilisé au niveau du package, ou s'il était appelé à l'intérieur d'une fonction sans résultat d'erreur, try paniquerait en rencontrant une erreur. (Soit dit en passant, à cause de cette propriété, la fonction intégrée a été appelée must plutôt que try dans cette proposition.)

Le consensus (interne de l'équipe Go) était qu'il serait déroutant pour try de dépendre du contexte et d'agir si différemment. Par exemple, ajouter un résultat d'erreur à une fonction (ou le supprimer) pourrait changer silencieusement le comportement de la fonction de paniquer à ne pas paniquer (ou vice versa).

@griesemer Merci pour la clarification sur la réécriture. Je suis content qu'il compile.

Je comprends que les exemples étaient des traductions qui n'annotaient pas les erreurs. J'ai tenté de faire valoir que try rend plus difficile la bonne annotation des erreurs dans des situations courantes, et que l'annotation des erreurs est très importante pour la communauté. Jusqu'à présent, une grande partie des commentaires ont exploré des moyens d'ajouter une meilleure prise en charge des annotations à try .

À propos de devoir gérer les erreurs différemment, je ne suis pas d'accord que c'est un signe que la préoccupation de la fonction est trop large. J'ai traduit quelques exemples de code réel revendiqué à partir des commentaires et les ai placés dans une liste déroulante au bas de mon commentaire d'origine , et l'exemple dans https://github.com/golang/go/issues/32437#issuecomment - 499007288, je pense, illustre bien un cas courant:

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) }
    // ...
}

Le but de cette fonction est d'exécuter un modèle sur certaines données dans un fichier. Je ne pense pas qu'il soit nécessaire de le diviser, et il serait regrettable que toutes ces erreurs gagnent la ligne sur laquelle elles ont été créées à partir d'un report. C'est peut-être bien pour les développeurs, mais c'est beaucoup moins utile pour les utilisateurs.

Je pense que c'est aussi un peu un signal à quel point les bogues defer wrap(&err, "message: %v", err) étaient subtils et comment ils ont fait trébucher même les programmeurs Go expérimentés.

Pour résumer mon argument : je pense que l'annotation d'erreur est plus importante que la vérification d'erreur basée sur l'expression, et nous pouvons obtenir une bonne réduction du bruit en permettant à la vérification d'erreur basée sur les instructions d'être sur une ligne au lieu de trois. Merci.

@griesemer désolé, j'ai lu une section différente qui parlait de panique et n'a pas vu la discussion sur les dangers.

@zeebo Merci pour cet exemple. Il semble que l'utilisation d'une instruction if soit exactement le bon choix dans ce cas. Mais point pris, le formatage des si en une seule ligne peut rationaliser un peu cela.

Je voudrais évoquer une fois de plus l'idée d'un gestionnaire comme deuxième argument de try , mais avec l'ajout que l'argument du gestionnaire soit _requis_, mais nil-able. Cela fait de la gestion de l'erreur la valeur par défaut, au lieu de l'exception. Dans les cas où vous voulez vraiment transmettre l'erreur inchangée, fournissez simplement une valeur nulle au gestionnaire et try se comportera comme dans la proposition d'origine, mais l'argument nul agira comme un indice visuel que le l'erreur n'est pas traitée. Il sera plus facile de s'en apercevoir lors de la révision du code.

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

Que doit-il se passer si le gestionnaire est fourni mais n'est pas ? Devriez-vous essayer de paniquer ou le traiter comme un gestionnaire d'erreurs absent ?

Comme mentionné ci-dessus, try se comportera conformément à la proposition initiale. Il n'y aurait pas de gestionnaire d'erreur absent, seulement un nul.

Que se passe-t-il si le gestionnaire est invoqué avec une erreur non nulle et renvoie ensuite un résultat nul ? Cela signifie-t-il que l'erreur est "annulée" ? Ou la fonction englobante doit-elle renvoyer une erreur nulle ?

Je crois que la fonction englobante reviendrait avec une erreur nulle. Ce serait potentiellement très déroutant si try pouvait parfois continuer l'exécution même après avoir reçu une valeur d'erreur non nulle. Cela permettrait aux gestionnaires de "prendre soin" de l'erreur dans certaines circonstances. Ce comportement peut être utile dans une fonction de style "obtenir ou créer", par exemple.

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)
}

Il n'était pas non plus clair si l'autorisation d'un gestionnaire d'erreurs facultatif conduirait les programmeurs à ignorer complètement la gestion appropriée des erreurs. Il serait également facile de gérer correctement les erreurs partout, mais de manquer une seule occurrence d'un essai. Et ainsi de suite.

Je crois que ces deux préoccupations sont atténuées en faisant du gestionnaire un argument obligatoire et nul. Cela nécessite que les programmeurs prennent une décision consciente et explicite qu'ils ne géreront pas leur erreur.

En prime, je pense que le fait d'exiger le gestionnaire d'erreurs décourage également les try profondément imbriqués car ils sont moins brefs. Certains pourraient voir cela comme un inconvénient, mais je pense que c'est un avantage.

@velovix J'adore l'idée, mais pourquoi le gestionnaire d'erreurs doit-il être requis ? Ne peut-il pas être nil par défaut ? Pourquoi avons-nous besoin d'un "indice visuel" ?

@griesemer Et si l'idée @velovix était adoptée mais avec builtin contenant une fonction prédéfinie qui convertit l'erreur en panique ET Nous supprimons l'exigence que la fonction globale ait une valeur de retour d'erreur?

L'idée est que si la fonction globale ne renvoie pas d'erreur, l'utilisation try sans gestionnaire d'erreur est une erreur de compilation.

Le gestionnaire d'erreurs peut également être utilisé pour envelopper l'erreur qui sera bientôt renvoyée en utilisant diverses bibliothèques, etc. à l'emplacement de l'erreur, au lieu d'un defer en haut qui modifie une erreur renvoyée nommée.

@pjebs

pourquoi le gestionnaire d'erreurs doit-il être requis ? Ne peut-il pas être nul par défaut ? Pourquoi avons-nous besoin d'un "indice visuel" ?

Il s'agit de répondre aux préoccupations que

1. La proposition try telle qu'elle est actuellement pourrait décourager les gens de fournir un contexte à leurs erreurs, car cela n'est pas si simple.

Le fait d'avoir un gestionnaire en premier lieu facilite la fourniture de contexte, et le fait que le gestionnaire soit un argument obligatoire envoie un message : le cas courant et recommandé consiste à gérer ou à contextualiser l'erreur d'une manière ou d'une autre, et non simplement à la transmettre dans la pile. C'est conforme à la recommandation générale de la communauté Go.

1. Une préoccupation du document de proposition d'origine. Je l'ai cité dans mon premier commentaire :

Il n'était pas non plus clair si l'autorisation d'un gestionnaire d'erreurs facultatif conduirait les programmeurs à ignorer complètement la gestion appropriée des erreurs. Il serait également facile de gérer correctement les erreurs partout, mais de manquer une seule occurrence d'un essai. Et ainsi de suite.

Le fait de devoir passer un nil explicite rend plus difficile d'oublier de gérer correctement une erreur. Vous devez explicitement décider de ne pas gérer l'erreur au lieu de le faire implicitement en omettant un argument.

Penser davantage au retour conditionnel brièvement mentionné sur https://github.com/golang/go/issues/32437#issuecomment -498947603.
Il semble
return if f, err := os.Open("/my/file/path"); err != nil
serait plus conforme à l'apparence if existante de Go.

Si nous ajoutons une règle pour l'instruction return if qui
lorsque la dernière expression de condition (comme err != nil ) n'est pas présente,et la dernière variable de la déclaration dans l'instruction return if est du type error ,alors la valeur de la dernière variable sera automatiquement comparée à nil comme condition implicite.

Ensuite, l'instruction return if peut être abrégée en :
return if f, err := os.Open("my/file/path")

Ce qui est très proche du rapport signal/bruit fourni par le try .
Si nous changeons le return if en try , il devient
try f, err := os.Open("my/file/path")
Cela redevient similaire aux autres variantes proposées du try dans ce fil, du moins syntaxiquement.
Personnellement, je préfère toujours return if à try dans ce cas car cela rend les points de sortie d'une fonction très explicites. Par exemple, lors du débogage, je mets souvent en surbrillance le mot-clé return dans l'éditeur pour identifier tous les points de sortie d'une grande fonction.

Malheureusement, cela ne semble pas non plus aider suffisamment avec l'inconvénient d'insérer la journalisation de débogage.
À moins que nous n'autorisions également un bloc body pour return if , comme
Original:

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

Lors du débogage :

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

La signification du bloc de corps de return if est évidente, je suppose. Il sera exécuté avant defer et retour.

Cela dit, je n'ai rien à redire sur l'approche de gestion des erreurs existante dans Go.
Je suis plus préoccupé par l'impact de l'ajout de la nouvelle gestion des erreurs sur la qualité actuelle de Go.

@velovix Nous avons bien aimé l'idée d'un try avec une fonction de gestionnaire explicite comme 2ème argument. Mais il y avait trop de questions qui n'avaient pas de réponses évidentes, comme l'indique le document de conception. Vous avez répondu à certaines d'entre elles d'une manière qui vous semble raisonnable. Il est fort probable (et c'était notre expérience au sein de l'équipe Go) que quelqu'un d'autre pense que la bonne réponse est tout à fait différente. Par exemple, vous indiquez que l'argument du gestionnaire doit toujours être fourni, mais qu'il peut être nil , pour le rendre explicite, nous ne nous soucions pas de gérer l'erreur. Maintenant, que se passe-t-il si l'on fournit une valeur de fonction (et non un littéral nil ) et que cette valeur de fonction (stockée dans une variable) est nulle ? Par analogie avec la valeur explicite nil , aucune manipulation n'est nécessaire. Mais d'autres pourraient dire qu'il s'agit d'un bogue dans le code. Ou, alternativement, on pourrait autoriser des arguments de gestionnaire de valeur nulle, mais une fonction pourrait alors gérer des erreurs de manière incohérente dans certains cas et pas dans d'autres, et ce n'est pas nécessairement évident d'après le code, car il semble qu'un gestionnaire est toujours présent . Un autre argument était qu'il est préférable d'avoir une déclaration de niveau supérieur d'un gestionnaire d'erreurs car cela indique très clairement que la fonction gère les erreurs. D'où le defer . Il y en a probablement plus.

Il serait bon d'en savoir plus sur cette préoccupation. Le style de codage actuel utilisant des instructions if pour tester les erreurs est à peu près aussi explicite que possible. Il est très facile d'ajouter des informations supplémentaires à une erreur, sur une base individuelle (pour chaque si). Souvent, il est logique de gérer toutes les erreurs détectées dans une fonction de manière uniforme, ce qui peut être fait avec un report - c'est déjà possible maintenant. C'est le fait que nous disposions déjà de tous les outils pour une bonne gestion des erreurs dans le langage, et le problème d'une construction de gestionnaire non orthogonale à différer, qui nous a conduit à laisser de côté un nouveau mécanisme uniquement pour augmenter les erreurs.

@griesemer - IIUC, vous dites que pour les contextes d'erreur dépendant du site d'appel, l'instruction if actuelle est correcte. Alors que cette nouvelle fonction try est utile dans les cas où la gestion de plusieurs erreurs à un seul endroit est utile.

Je pense que le problème était que, bien que le simple fait de faire un if err != nil { return err} puisse convenir dans certains cas, il est généralement recommandé de décorer l'erreur avant de revenir. Et cette proposition semble répondre à la précédente et ne fait pas grand-chose pour la seconde. Ce qui signifie essentiellement que les gens seront encouragés à utiliser un modèle de retour facile.

@agnivade Vous avez raison, cette proposition ne fait exactement rien pour aider à la décoration des erreurs (mais pour recommander l'utilisation de defer ). L'une des raisons est que des mécanismes linguistiques pour cela existent déjà. Dès qu'une décoration d'erreur est requise, en particulier sur une base d'erreur individuelle, la quantité supplémentaire de texte source pour le code de décoration rend le if moins onéreux en comparaison. Ce sont les cas où aucune décoration n'est requise, ou où la décoration est toujours la même, où le passe-partout devient une nuisance visible et nuit alors au code important.

Les gens sont déjà encouragés à utiliser un modèle de retour facile, try ou pas try , il y a juste moins à écrire. À bien y penser, _la seule façon d'encourager la décoration des erreurs est de la rendre obligatoire_, car quelle que soit la langue disponible, la décoration des erreurs nécessitera plus de travail.

Une façon d'adoucir l'affaire serait de n'autoriser quelque chose comme try (ou toute notation de raccourci analogue) _si_ un gestionnaire explicite (éventuellement vide) est fourni quelque part (notez que le brouillon original n'avait pas un tel exigence non plus).

Je ne suis pas sûr qu'on veuille aller aussi loin. Permettez-moi de réaffirmer que beaucoup de code parfaitement fin, disons les composants internes d'une bibliothèque, n'ont pas besoin de décorer les erreurs partout. C'est bien de simplement propager les erreurs et de les décorer juste avant qu'elles ne quittent les points d'entrée de l'API, par exemple. (En fait, les décorer partout ne conduira qu'à des erreurs sur-décorées qui, avec les vrais coupables cachés, rendront plus difficile la localisation des erreurs importantes ; tout comme une journalisation trop détaillée peut rendre difficile de voir ce qui se passe réellement).

Je pense que nous pouvons également ajouter une fonction catch , ce qui serait une belle paire, donc :

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
}

dans cet exemple, catch() serait recover() une panique et return ..., panicValue .
bien sûr, nous avons un cas évident dans lequel nous avons une fonction, qui renvoie également une erreur. dans ce cas, je pense qu'il serait pratique de simplement transmettre la valeur d'erreur.

donc, en gros, vous pouvez ensuite utiliser catch() pour récupérer les paniques() et les transformer en erreurs.
cela me semble assez drôle, car Go n'a pas réellement d'exceptions, mais dans ce cas, nous avons un modèle try()-catch() assez soigné, qui ne devrait pas non plus faire exploser toute votre base de code avec quelque chose comme Java ( catch(Throwable) dans Main + throws LiterallyAnything ). vous pouvez facilement traiter les paniques de quelqu'un comme si c'était des erreurs habituelles. J'ai actuellement environ 6 millions de LoC en Go dans mon projet actuel, et je pense que cela simplifierait les choses au moins pour moi.

@griesemer Merci pour votre récapitulatif de la discussion.

Je remarque qu'il manque un point là-dedans : certaines personnes ont fait valoir que nous devrions attendre avec cette fonctionnalité jusqu'à ce que nous ayons des génériques, ce qui, espérons-le, nous permettra de résoudre ce problème de manière plus élégante.

De plus, j'aime aussi la suggestion de @velovix , et bien que j'apprécie que cela soulève quelques questions comme décrit dans la spécification, je pense qu'il est facile d'y répondre de manière raisonnable, comme @velovix l' a déjà fait.

Par exemple:

• Que se passe-t-il si l'on fournit une valeur de fonction (pas un littéral nul) et que cette valeur de fonction (stockée dans une variable) se trouve être nulle ? => Ne pas gérer l'erreur, point final. Ceci est utile dans le cas où la gestion des erreurs dépend du contexte et la variable du gestionnaire est définie selon que la gestion des erreurs est requise ou non. Ce n'est pas un bug, c'est plutôt une fonctionnalité. :)

• Un autre argument était qu'il est préférable d'avoir une déclaration de niveau supérieur d'un gestionnaire d'erreurs car cela indique très clairement que la fonction gère les erreurs. => Définissez donc le gestionnaire d'erreurs en haut de la fonction en tant que fonction de fermeture nommée et utilisez-la, il est donc également très clair que l'erreur doit être gérée. Ce n'est pas un problème sérieux, plus une exigence de style.

Quelles autres préoccupations y avait-il? Je suis presque sûr qu'on peut tous y répondre de la même manière d'une manière raisonnable.

Enfin, comme vous le dites, "une façon d'adoucir l'affaire serait de n'autoriser quelque chose comme try (ou toute notation de raccourci analogue) que si un gestionnaire explicite (éventuellement vide) est fourni quelque part". Je pense que si nous voulons aller de l'avant avec cette proposition, nous devrions en fait aller "jusqu'ici", pour encourager une gestion des erreurs appropriée, "explicite vaut mieux qu'implicite".

@griesemer

Maintenant, que se passe-t-il si l'on fournit une valeur de fonction (pas un littéral nil) et que cette valeur de fonction (stockée dans une variable) se trouve être nil ? Par analogie avec la valeur nulle explicite, aucune manipulation n'est nécessaire. Mais d'autres pourraient dire qu'il s'agit d'un bogue dans le code.

En théorie, cela semble être un piège potentiel, même si j'ai du mal à conceptualiser une situation raisonnable où un gestionnaire finirait par être nul par accident. J'imagine que les gestionnaires proviendraient le plus souvent soit d'une fonction d'utilité définie ailleurs, soit d'une fermeture définie dans la fonction elle-même. Ni l'un ni l'autre ne sont susceptibles de devenir nuls de manière inattendue. Vous pourriez théoriquement avoir un scénario où les fonctions de gestionnaire sont transmises en tant qu'arguments à d'autres fonctions, mais à mes yeux, cela semble plutôt tiré par les cheveux. Peut-être y a-t-il un modèle comme celui-ci dont je ne suis pas au courant.

Un autre argument était qu'il est préférable d'avoir une déclaration de niveau supérieur d'un gestionnaire d'erreurs car cela indique très clairement que la fonction gère les erreurs. D'où le defer .

Comme @beoran l'a mentionné, définir le gestionnaire comme une fermeture près du haut de la fonction aurait un style très similaire, et c'est ainsi que je m'attends personnellement à ce que les gens utilisent le plus souvent les gestionnaires. Bien que j'apprécie la clarté gagnée par le fait que toutes les fonctions qui gèrent les erreurs utiliseront defer , cela peut devenir moins clair lorsqu'une fonction doit pivoter dans sa stratégie de gestion des erreurs à mi-chemin de la fonction. Ensuite, il y aura deux defer à regarder et le lecteur devra raisonner sur la façon dont ils interagiront l'un avec l'autre. C'est une situation où je pense qu'un argument de gestionnaire serait à la fois plus clair et ergonomique, et je pense que ce sera un scénario _relativement_ courant.

Est-il possible de le faire fonctionner sans crochets ?

C'est à dire quelque chose comme :
a := try func(some)

@Cyberax - Comme déjà mentionné ci-dessus, il est essentiel que vous lisiez attentivement le document de conception avant de publier. Puisqu'il s'agit d'un problème à fort trafic, avec beaucoup de personnes abonnées.

La doc discute en détail des opérateurs et des fonctions.

J'aime beaucoup plus cette version que j'ai aimé la version d'août.

Je pense qu'une grande partie des commentaires négatifs, qui ne sont pas carrément opposés aux retours sans le mot-clé return , peuvent être résumés en deux points :

1. les gens n'aiment pas les paramètres de résultat nommés, qui deviendraient obligatoires dans la plupart des cas
2. cela décourage l'ajout d'un contexte détaillé aux erreurs

Voir par exemple :

• 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

La réfutation de ces deux objections est respectivement :

1. "nous avons décidé que [paramètres de résultat nommés] étaient corrects"
2. "Personne ne va vous faire utiliser try " / ça ne va pas convenir à 100% des cas

Je n'ai vraiment rien à dire sur 1 (je n'y tiens pas vraiment). Mais concernant 2, je noterais que la proposition auguste n'avait pas ce problème, la plupart des contre-propositions n'ont pas non plus ce problème.

En particulier, ni la contre-proposition tryf (qui a été publiée deux fois indépendamment dans ce fil) ni la contre-proposition try(X, handlefn) (qui faisait partie des itérations de conception) n'avaient ce problème.

Je pense qu'il est difficile d'affirmer que try , tel qu'il est, éloignera les gens de la décoration des erreurs avec un contexte pertinent et vers une seule décoration d'erreur générique par fonction.

Pour ces raisons, je pense qu'il vaut la peine d'essayer de résoudre ce problème et je souhaite proposer une solution possible :

1. Actuellement, le paramètre de defer ne peut être qu'un appel de fonction ou de méthode. Autoriser defer à avoir également un nom de fonction ou un littéral de fonction, c'est-à-dire

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

1. Lorsque panique ou deferreturn rencontrent ce type de report, ils appellent la fonction en passant la valeur zéro pour tous leurs paramètres

2. Autoriser try à avoir plus d'un paramètre

3. Lorsque try rencontre le nouveau type de report, il appelle la fonction en passant un pointeur vers la valeur d'erreur comme premier paramètre suivi de tous les paramètres propres try , sauf le premier.

Par exemple, étant donné :

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)
    }
}

ce qui suit se produira :

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

Le code dans https://github.com/golang/go/issues/32437#issuecomment -499309304 par @zeebo pourrait alors être réécrit comme suit :

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)
    // ...
}

Et définir ErrorHandlef comme :

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

donnerait à tout le monde le très recherché tryf gratuitement, sans extraire les chaînes de format de style fmt dans le langage de base.

Cette fonctionnalité est rétrocompatible car defer n'autorise pas les expressions de fonction comme argument. Il n'introduit pas de nouveaux mots-clés.
Les modifications qui doivent être apportées pour l'implémenter, en plus de celles décrites dans https://github.com/golang/proposal/blob/master/design/32437-try-builtin.md , sont :

1. enseigner à l'analyseur le nouveau type de report
2. changer le vérificateur de type pour vérifier qu'à l'intérieur d'une fonction tous les reports qui ont une fonction en paramètre (au lieu d'un appel) ont aussi la même signature
3. changer le vérificateur de type pour vérifier que les paramètres passés à try correspondent à la signature des fonctions passées à defer
4. changer le backend (?) pour générer l'appel deferproc approprié
5. modifier l'implémentation de try pour copier ses arguments dans les arguments de l'appel différé lorsqu'il rencontre un appel différé par le nouveau type de report.

Après les complexités de la conception du brouillon de check/handle , j'ai été agréablement surpris de voir cette proposition beaucoup plus simple et pragmatique, bien que je sois déçu qu'il y ait eu tant de refoulement contre elle.

Certes, une grande partie de la réticence vient de personnes qui sont assez satisfaites de la verbosité actuelle (une position parfaitement raisonnable à prendre) et qui n'accueilleraient vraisemblablement pas vraiment toute proposition pour l'atténuer. Pour le reste d'entre nous, je pense que cette proposition a le mérite d'être simple et de ressembler à Go, de ne pas essayer d'en faire trop et de bien s'accorder avec les techniques de gestion des erreurs existantes sur lesquelles vous pouvez toujours vous rabattre si try n'a pas fait exactement ce que vous vouliez.

Concernant certains points particuliers :

1. La seule chose que je n'aime pas dans la proposition est la nécessité d'avoir un paramètre de retour d'erreur nommé lorsque defer est utilisé mais, cela dit, je ne peux penser à aucune autre solution qui ne serait pas en contradiction avec la façon dont le reste de la langue fonctionne. Je pense donc que nous devrons simplement l'accepter si la proposition est adoptée.

2. Il est dommage que try ne fonctionne pas bien avec le package de test pour les fonctions qui ne renvoient pas de valeur d'erreur. Ma propre solution préférée à cela serait d'avoir une deuxième fonction intégrée (peut-être ptry ou must ) qui paniquait toujours plutôt que de revenir en rencontrant une erreur non nulle et qui pourrait donc être utilisé avec les fonctions susmentionnées (y compris main ). Bien que cette idée ait été rejetée dans la présente itération de la proposition, j'ai eu l'impression qu'il s'agissait d'un « appel de proximité » et qu'elle pourrait donc être réexaminée.

3. Je pense qu'il serait difficile pour les gens de comprendre ce que go try(f) ou defer try(f) faisaient et qu'il est donc préférable de les interdire complètement.

4. Je suis d'accord avec ceux qui pensent que les techniques de gestion des erreurs existantes auraient l'air moins détaillées si go fmt ne réécrivait pas les déclarations if seule ligne. Personnellement, je préférerais une règle simple selon laquelle cela serait autorisé pour _toute_ déclaration unique if , qu'elle concerne ou non la gestion des erreurs. En fait, je n'ai jamais été en mesure de comprendre pourquoi cela n'est pas actuellement autorisé lors de l'écriture de fonctions à une seule ligne où le corps est placé sur la même ligne que la déclaration est autorisée.

En cas d'erreurs de décoration

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

Cela semble considérablement plus verbeux et douloureux que les paradigmes existants, et pas aussi concis que check/handle. La variante try() sans encapsulation est plus concise, mais on a l'impression que les gens finiront par utiliser un mélange d'essais et de retours d'erreur simples. Je ne suis pas sûr d'aimer l'idée de mélanger les retours d'essais et d'erreurs simples, mais je suis totalement convaincu des erreurs de décoration (et j'attends avec impatience Is/As). Faites-moi penser que même si c'est syntaxiquement soigné, je ne suis pas sûr de vouloir l'utiliser réellement. check/handle senti quelque chose que j'embrasserais plus complètement.

J'aime vraiment la simplicité de cela et l'approche "faire bien une chose". Dans mon interpréteur GoAWK , ce serait très utile - j'ai environ 100 constructions if err != nil { return nil } qui simplifieraient et rangeraient, et c'est dans une base de code assez petite.

J'ai lu la justification de la proposition pour en faire une fonction intégrée plutôt qu'un mot-clé, et cela revient à ne pas avoir à ajuster l'analyseur. Mais n'est-ce pas une douleur relativement faible pour les compilateurs et les rédacteurs d'outils, alors que le fait d'avoir les parenthèses supplémentaires et les problèmes de lisibilité de ceci-ressemble-à-une-fonction-mais-n'est-ce pas sera quelque chose que tous les codeurs et code Go- les lecteurs doivent endurer. À mon avis, l'argument (excuse ? :-) selon lequel "mais panic() contrôle le flux" ne suffit pas, car la panique et la récupération sont, par leur nature même, exceptionnelles , alors que try() le fera être la gestion normale des erreurs et le flux de contrôle.

Je l'apprécierais certainement même si cela se passait tel quel, mais ma forte préférence serait que le flux de contrôle normal soit clair, c'est-à-dire effectué via un mot-clé.

Je suis favorable à cette proposition. Cela évite ma plus grande réserve à propos de la proposition précédente : la non-orthogonalité de handle par rapport à defer .

Je voudrais mentionner deux aspects qui, je pense, n'ont pas été mis en évidence ci-dessus.

Tout d'abord, bien que cette proposition ne facilite pas l'ajout d'un texte d'erreur spécifique au contexte à une erreur, elle facilite l'ajout d'informations de traçage d'erreur de cadre de pile à une erreur : https://play.golang.org/p /YL1MoqR08E6

Deuxièmement, try est sans doute une solution équitable à la plupart des problèmes sous-jacents https://github.com/golang/go/issues/19642. Pour prendre un exemple de ce problème, vous pouvez utiliser try pour éviter d'écrire toutes les valeurs de retour à chaque fois. Ceci est également potentiellement utile lors du retour de types de structure par valeur avec des noms longs.

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
}

J'aime aussi cette proposition.

Et j'ai une demande.

Comme make , pouvons-nous autoriser try à prendre un nombre variable de paramètres

• essayer(f):
  comme ci-dessus.
  une valeur d'erreur de retour est obligatoire (comme dernier paramètre de retour).
  MODÈLE D'UTILISATION LE PLUS COURANT
• try(f, doPanic bool):
  comme ci-dessus, mais si doPanic, alors panique (erreur) au lieu de revenir.
  Dans ce mode, une valeur d'erreur de retour n'est pas nécessaire.
• essayer(f, fn):
  comme ci-dessus, mais appelez fn(err) avant de revenir.
  Dans ce mode, une valeur d'erreur de retour n'est pas nécessaire.

De cette façon, c'est un intégré qui peut gérer tous les cas d'utilisation, tout en étant explicite. Ses avantages :

• toujours explicite - pas besoin de déduire s'il faut paniquer ou définir une erreur et revenir
• prend en charge le gestionnaire spécifique au contexte (mais pas de chaîne de gestionnaire)
• prend en charge les cas d'utilisation où il n'y a pas de variable de retour d'erreur
• prend en charge la sémantique must(...)

Bien que if err !=nil { return ... err } répétitif soit certainement un vilain bégaiement, je suis avec ceux
qui pensent que la proposition try() est très peu lisible et quelque peu inexplicite.
L'utilisation de retours nommés est également problématique.

Si ce type de rangement est nécessaire, pourquoi ne pas try(err) comme sucre syntaxique pour
if err !=nil { return err } :

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

pour

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

Et s'il y a plus d'une valeur de retour, try(err) pourrait return t1, ... tn, err
où t1, ... tn sont les valeurs nulles des autres valeurs de retour.

Cette suggestion peut éviter le besoin de valeurs de retour nommées et être,
à mon avis, plus facile à comprendre et plus lisible.

Encore mieux, je pense que ce serait :

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

Ou même

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

Ce dernier est rétrocompatible (? n'est actuellement pas autorisé dans les identifiants).

(Cette suggestion est liée à https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring-themes. Mais les exemples de thèmes récurrents semblent différents car c'était à un stade où une poignée explicite était encore en cours de discussion au lieu de partir cela à un report.)

Merci à l'équipe go pour cette proposition soignée et intéressante.

@rogpeppe commente si try ajoute automatiquement le cadre de la pile, pas moi, je suis d'accord pour décourager l'ajout de contexte.

@aarzilli - Donc, selon votre proposition, une clause de report est-elle obligatoire à chaque fois que nous donnons des paramètres supplémentaires à tryf ?

Que se passe-t-il si je fais

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

et ne pas écrire de fonction différée ?

@agnivade

Que se passe-t-il si je fais (...) et que je n'écris pas de fonction différée ?

erreur de vérification de type.

À mon avis, utiliser try pour éviter d'écrire toutes les valeurs de retour n'est en fait qu'une autre attaque contre elle.

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

Je comprends parfaitement le désir d'éviter d'avoir à écrire return nil, 0, 0, ErrNotFound , mais je préférerais de loin résoudre cela d'une autre manière.

Le mot try ne signifie pas "retour". Et c'est ainsi qu'il est utilisé ici. Je préférerais en fait que la proposition change pour que try ne puisse pas prendre une error directement, car je ne veux jamais que quelqu'un écrive du code comme ça ^^ . Il se lit mal . Si vous montriez ce code à un débutant, il n'aurait aucune idée de ce que faisait cet essai.

Si nous voulons un moyen de renvoyer facilement les valeurs par défaut et une valeur d'erreur, résolvons cela séparément. Peut-être un autre intégré comme

return default(ErrNotFound)

Au moins, cela se lit avec une sorte de logique.

Mais n'abusons pas de try pour résoudre un autre problème.

@natefinch si le try intégré est nommé check comme dans la proposition originale, ce serait check(err) qui se lit beaucoup mieux, imo.

Cela mis à part, je ne sais pas si c'est vraiment un abus d'écrire try(err) . Cela tombe clairement hors de la définition. Mais, d'un autre côté, cela signifie aussi que c'est légal :

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

Je suppose que mon principal problème avec try est que c'est vraiment juste un panic qui ne monte que d'un niveau... sauf que contrairement à la panique, c'est une expression, pas une déclaration, donc vous pouvez cacher au milieu d'une déclaration quelque part. C'est presque pire que la panique.

@natefinch Si vous le conceptualisez comme une panique qui monte d'un niveau et fait ensuite d'autres choses, cela semble assez désordonné. Cependant, je le conceptualise différemment. Les fonctions qui renvoient des erreurs dans Go renvoient effectivement un résultat, pour emprunter librement la terminologie de Rust. try est un utilitaire qui décompresse le résultat et soit renvoie un "résultat d'erreur" si error != nil , soit décompresse la partie T du résultat si error == nil .

Bien sûr, dans Go, nous n'avons pas réellement d'objets de résultat, mais c'est effectivement le même modèle et try semble être une codification naturelle de ce modèle. Je pense que toute solution à ce problème devra codifier certains aspects de la gestion des erreurs, et try s'en chargent me semblent raisonnables. Moi-même et d'autres suggérons d'étendre un peu la capacité de try pour mieux s'adapter aux modèles de gestion des erreurs Go existants, mais le concept sous-jacent reste le même.

@ugorji La variante try(f, bool) que vous proposez ressemble au must de #32219.

@ugorji La variante try(f, bool) que vous proposez ressemble au must de #32219.

Oui c'est le cas. J'avais juste l'impression que les 3 cas pouvaient être traités avec une fonction intégrée unique et satisfaire tous les cas d'utilisation avec élégance.

Étant donné que try() est déjà magique et conscient de la valeur de retour d'erreur, pourrait-il être augmenté pour renvoyer également un pointeur vers cette valeur lorsqu'il est appelé sous la forme nullaire (argument zéro) ? Cela éliminerait le besoin de retours nommés et, je pense, aiderait à corréler visuellement d'où l'erreur devrait provenir dans les instructions différées. Par exemple:

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

@ugorji
Je pense que le booléen sur try(f, bool) le rendrait difficile à lire et facile à manquer. J'aime votre proposition, mais pour le cas de panique, je pense que cela pourrait être laissé de côté pour que les utilisateurs l'écrivent à l'intérieur du gestionnaire à partir de votre troisième puce, par exemple try(f(), func(err error) { panic('at the disco'); }) , cela le rend plus explicite pour les utilisateurs qu'un try(f(), true) caché

@ugorji
Je pense que le booléen sur try(f, bool) le rendrait difficile à lire et facile à manquer. J'aime votre proposition, mais pour le cas de panique, je pense que cela pourrait être laissé de côté pour que les utilisateurs l'écrivent à l'intérieur du gestionnaire à partir de votre troisième puce, par exemple try(f(), func(err error) { panic('at the disco'); }) , cela le rend plus explicite pour les utilisateurs qu'un try(f(), true) caché

Après réflexion, j'ai tendance à être d'accord avec votre position et votre raisonnement, et cela a toujours l'air élégant en tant que one-liner.

@patrick-nyt est encore un autre partisan de la _syntaxe d'affectation_ pour déclencher un test nul, dans https://github.com/golang/go/issues/32437#issuecomment -499533464

Ce concept apparaît dans 13 réponses distinctes à la proposition check/handle
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback#recurring -themes

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

Pourquoi? Parce qu'il se lit comme Go 1, alors que try() et check ne le font pas.

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

Une objection à try semble être qu'il s'agit d'une expression. Supposons à la place qu'il existe une instruction postfixée unaire ? qui signifie retour si non nul. Voici l'exemple de code standard (en supposant que mon package différé proposé est ajouté):

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
}

L'exemple pgStore :

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()
}

J'aime ça de @jargv :

Étant donné que try() est déjà magique et conscient de la valeur de retour d'erreur, pourrait-il être augmenté pour renvoyer également un pointeur vers cette valeur lorsqu'il est appelé sous la forme nullaire (argument zéro) ? Cela éliminerait le besoin de retours nommés

Mais au lieu de surcharger le nom try en fonction du nombre d'arguments, je pense qu'il pourrait y avoir une autre magie intégrée, disons reterr ou quelque chose du genre.

J'ai passé en revue certains packages très souvent utilisés, à la recherche de code go qui "souffre" de la gestion des erreurs mais qui doit avoir été bien pensé avant d'être écrit, en essayant de comprendre quelle "magie" le try() proposé ferait.
Actuellement, à moins que j'aie mal compris la proposition, beaucoup d'entre eux (par exemple, pas une gestion des erreurs super basique) ne gagneraient pas grand-chose, ou devraient rester avec le "vieux" style de gestion des erreurs.
Exemple tiré de 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

}
`

ou tel qu'utilisé dans un test approfondi tel que pprof/profile/profile_test.go :
`
func checkAggregation(prof *Profile, a *aggTest) erreur {
// Vérifie que le nombre total d'échantillons pour les lignes a été conservé.
totale := 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

}
`
Ce sont deux exemples auxquels je peux penser dans lesquels on dirait : "Je voudrais une meilleure option de gestion des erreurs"

Quelqu'un peut-il démontrer comment ceux-ci s'amélioreraient en utilisant try() ?

Je suis majoritairement favorable à cette proposition.

Ma principale préoccupation, partagée avec de nombreux commentateurs, concerne les paramètres de résultat nommés. La proposition actuelle encourage certainement beaucoup plus l'utilisation de paramètres de résultat nommés et je pense que ce serait une erreur. Je ne crois pas que ce soit simplement une question de style comme l'indique la proposition : les résultats nommés sont une caractéristique subtile du langage qui, dans de nombreux cas, rend le code plus sujet aux bogues ou moins clair. Après environ 8 ans de lecture et d'écriture de code Go, je n'utilise vraiment que des paramètres de résultat nommés à deux fins :

• Documentation des paramètres de résultat
• Manipulation d'une valeur de résultat (généralement un error ) dans un délai

Pour attaquer ce problème dans une nouvelle direction, voici une idée qui, à mon avis, ne correspond pas étroitement à tout ce qui a été discuté dans le document de conception ou dans ce fil de commentaires sur le problème. Appelons-le "report d'erreur":

Autoriser l'utilisation du report pour appeler des fonctions avec un paramètre d'erreur implicite.

Donc, si vous avez une fonction

func f(err error, t1 T1, t2 T2, ..., tn Tn) error

Ensuite, dans une fonction g où le dernier paramètre de résultat a le type error (c'est-à-dire, toute fonction où try peut être utilisé), un appel à f peut être reporté comme suit :

func g() (R0, R0, ..., error) {
    defer f(t0, t1, ..., tn) // err is implicit
}

La sémantique de error-defer est :

1. L'appel différé à f est appelé avec le dernier paramètre de résultat de g comme premier paramètre d'entrée de f
2. f n'est appelé que si cette erreur n'est pas nulle
3. Le résultat de f est affecté au dernier paramètre de résultat de g

Donc, pour utiliser un exemple de l'ancien document de conception de gestion des erreurs, en utilisant error-defer et try, nous pourrions faire

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
}

Voici comment HandleErrorf fonctionnerait :

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)...)
}

Un cas particulier qui devrait être résolu est de savoir comment gérer les cas où la forme de report que nous utilisons est ambiguë. Je pense que cela ne se produit qu'avec des fonctions (très inhabituelles) avec des signatures comme celle-ci :

func(error, ...error) error

Il semble raisonnable de dire que ce cas est traité de manière non différée (et cela préserve la compatibilité descendante).

En pensant à cette idée depuis quelques jours, c'est un peu magique, mais le fait d'éviter les paramètres de résultat nommés est un grand avantage en sa faveur. Étant donné que try encourage une utilisation accrue de defer pour la manipulation des erreurs, il est logique que defer puisse être étendu pour mieux l'adapter à cette fin. De plus, il existe une certaine symétrie entre try et le report d'erreur.

Enfin, les reports d'erreurs sont utiles aujourd'hui même sans essai, car ils remplacent l'utilisation de paramètres de résultat nommés pour manipuler les retours d'erreur. Par exemple, voici une version modifiée d'un code réel :

// 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)
                }
            }
        }
    }()

    // ...
}

Avec le report d'erreur, cela devient :

// 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 Concernant votre commentaire selon lequel nous devrions attendre les génériques. Les génériques ne vous aideront pas ici - veuillez lire la FAQ .

En ce qui concerne vos suggestions sur le comportement par défaut du try 2 arguments de @velovix : comme je l'ai déjà dit, votre idée de ce qui est le choix évidemment raisonnable est le cauchemar de quelqu'un d'autre.

Puis-je suggérer que nous poursuivions cette discussion une fois qu'un large consensus aura émergé sur le fait que try avec un gestionnaire d'erreurs explicite est une meilleure idée que le try minimal actuel. À ce stade, il est logique de discuter des subtilités d'une telle conception.

(J'aime bien avoir un gestionnaire, d'ailleurs. C'est l'une de nos propositions précédentes. Et si nous adoptons try tel quel, nous pouvons toujours passer à un try avec un gestionnaire dans un avant -compatibilité - du moins si le gestionnaire est facultatif. Mais procédons une étape à la fois.)

@aarzilli Merci pour votre suggestion .

Tant que les erreurs de décoration sont facultatives, les gens auront tendance à ne pas le faire (c'est du travail supplémentaire après tout). Voir aussi mon commentaire ici .

Donc, je ne pense pas que le try proposé _décourage_ les gens à faire des erreurs de décoration (ils sont déjà découragés même avec le if pour la raison ci-dessus) ; c'est que try ne l'encourage pas.

(Une façon de l'encourager est de le lier à try : on ne peut utiliser try que si l'on décore également l'erreur ou si l'on se désengage explicitement.)

Mais revenons à vos suggestions : je pense que vous introduisez beaucoup plus de machines ici. Changer la sémantique de defer juste pour qu'elle fonctionne mieux pour try n'est pas quelque chose que nous voudrions considérer à moins que ces changements defer soient bénéfiques d'une manière plus générale. De plus, votre suggestion lie defer à try et rend ainsi ces deux mécanismes moins orthogonaux ; quelque chose que nous voudrions éviter.

Mais plus important encore, je doute que vous vouliez forcer tout le monde à écrire un defer juste pour pouvoir utiliser try . Mais sans faire cela, nous revenons à la case départ : les gens pencheront pour ne pas décorer les erreurs.

(J'aime bien avoir un gestionnaire, d'ailleurs. C'est l'une de nos propositions précédentes. Et si nous adoptons try tel quel, nous pouvons toujours passer à un essai avec un gestionnaire d'une manière compatible vers l'avant - du moins si le gestionnaire est facultatif. Mais procédons une étape à la fois.)

Bien sûr, une approche en plusieurs étapes est peut-être la voie à suivre. Si nous ajoutons un argument de gestionnaire facultatif à l'avenir, un outil pourrait être créé pour avertir l'auteur d'un try non géré dans le même esprit que l'outil errcheck . Quoi qu'il en soit, j'apprécie vos commentaires!

@alanfo Merci pour vos commentaires positifs.

Concernant les points que vous avez soulevés :

1) Si le seul problème avec try est le fait qu'il faudra nommer un retour d'erreur afin que nous puissions décorer une erreur via defer , je pense que nous sommes bons. Si nommer le résultat s'avère être un vrai problème, nous pourrions y remédier. Un mécanisme simple auquel je peux penser serait une variable prédéclarée qui est un alias vers un résultat d'erreur (pensez-y comme contenant l'erreur qui a déclenché le plus récent try ). Il peut y avoir de meilleures idées. Nous ne l'avons pas proposé car il existe déjà un mécanisme dans le langage, qui consiste à nommer le résultat.
2) try et tests : cela peut être résolu et mis en œuvre. Voir la doc détaillée.
3) Ceci est explicitement abordé dans la doc détaillée.
4) Reconnu.

@benhoyt Merci pour vos commentaires positifs.

Si le principal argument contre cette proposition est le fait que try est intégré, nous sommes bien placés. L'utilisation d'un intégré est simplement une solution pragmatique au problème de rétrocompatibilité (il arrive qu'il n'y ait pas de travail supplémentaire pour l'analyseur, les outils, etc. - mais c'est juste un avantage secondaire intéressant, pas la raison principale). Il y a aussi quelques avantages à devoir écrire des parenthèses, ceci est discuté en détail dans le document de conception (section sur les propriétés de la conception proposée).

Cela dit, si l'utilisation d'un élément intégré est le clou du spectacle, nous devrions envisager le mot-clé try . Il ne sera cependant pas rétrocompatible avec le code existant car le mot-clé peut entrer en conflit avec les identifiants existants.

(Pour être complet, il y a aussi l'option d'un opérateur tel que ? , qui serait rétrocompatible. Cela ne me semble pas être le meilleur choix pour un langage tel que Go, cependant. Mais encore une fois, si c'est tout ce qu'il faut pour rendre try agréable au goût, nous devrions peut-être l'envisager.)

@ugorji Merci pour vos commentaires positifs.

try pourrait être étendu pour prendre un argument supplémentaire. Notre préférence serait de ne prendre qu'une fonction avec la signature func (error) error . Si vous voulez paniquer, il est facile de fournir une fonction d'assistance en une ligne :

func doPanic(err error) error { panic(err) }

Mieux vaut garder la conception de try simple.

@patrick-nyt Ce que vous proposez :

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

sera possible avec la proposition actuelle.

@dpinela , @ugorji Veuillez également lire la doc de conception au sujet de must vs try . Il est préférable de garder try aussi simple que possible. must est un "modèle" courant dans les expressions d'initialisation, mais il n'est pas urgent de "réparer" cela.

@jargv Merci pour votre suggestion . C'est une idée intéressante (voir aussi mon commentaire ici à ce sujet). Résumer:

• try(x) fonctionne comme proposé
• try() renvoie un *error pointant vers le résultat de l'erreur

Ce serait en effet une autre façon d'arriver au résultat sans avoir à le nommer.

@cespare La suggestion de @jargv me semble beaucoup plus simple que ce que vous proposez . Il résout le même problème d'accès à l'erreur de résultat. Qu'est-ce que tu penses?

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

func doPanic(err error) error { panique(err) }

Je prévois que cette fonction serait assez courante. Cela pourrait-il être prédéfini dans "builtin" (ou ailleurs dans un package standard, par exemple errors ) ?

Dommage que vous ne prévoyiez pas des génériques assez puissants à mettre en place
essayer, j'aurais en fait espéré qu'il serait possible de le faire.

Oui, cette proposition pourrait être une première étape, même si je n'y vois pas beaucoup d'utilité
moi-même tel qu'il est maintenant.

Certes, ce numéro met peut-être trop l'accent sur des alternatives détaillées,
mais cela montre que de nombreux participants ne sont pas entièrement satisfaits
ce. Ce qui semble faire défaut, c'est un large consensus autour de cette proposition...

Op vr 7 juin. 2019 01:04 schreef pj [email protected] :

Asper #32437 (commentaire)
https://github.com/golang/go/issues/32437#issuecomment-499320588 :

func doPanic(err error) error { panique(err) }

Je prévois que cette fonction serait assez courante. Cela pourrait-il être prédéfini
dans "intégré" ?

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=AAARM6OOOLLYO5ZCE6VVL2TPZGJWRA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXEMYZY#issuecomment-49196,9
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAARM6K5AOR2DES4QDTNLSTPZGJWRANCNFSM4HTGCZ7Q
.

@pjebs , j'ai écrit la fonction équivalente des dizaines de fois. Je l'appelle généralement "orDie" ou "check". C'est si simple qu'il n'est pas vraiment nécessaire de l'intégrer à la bibliothèque standard. De plus, différentes personnes peuvent vouloir se connecter ou quoi que ce soit avant la résiliation.

@beoran Vous pourriez peut-être développer le lien entre les génériques et la gestion des erreurs. Quand je pense à eux, ils semblent être deux choses différentes. Les génériques ne sont pas un fourre-tout qui peut résoudre tous les problèmes avec la langue. C'est la capacité d'écrire une seule fonction qui peut fonctionner sur plusieurs types.

Cette proposition spécifique de gestion des erreurs tente de réduire le passe-partout en introduisant une fonction prédéclarée try qui modifie le contrôle de flux dans certaines circonstances. Les génériques ne changeront jamais le flux de contrôle. Donc je ne vois vraiment pas le rapport.

Ma première réaction à cela a été un 👎 car j'imaginais que la gestion de plusieurs appels sujets aux erreurs dans une fonction rendrait le gestionnaire d'erreur defer déroutant. Après avoir lu toute la proposition, j'ai inversé ma réaction à un ❤️ et 👍 car j'ai appris que cela peut encore être réalisé avec une complexité relativement faible.

@carlmjohnson Oui c'est simple mais...

J'ai écrit la fonction équivalente des dizaines de fois.

Les avantages d'une fonction prédéclarée sont :

1. Nous pouvons le mettre en ligne
2. Nous n'avons pas besoin de redéclarer la fonction err => panic dans chaque paquet que nous utilisons, ou de conserver un emplacement commun pour celle-ci. Puisqu'il est probablement commun à tout le monde dans la communauté Go, le "paquet standard" est _ l' _ emplacement commun pour celui-ci.

@griesemer Avec la variante de gestionnaire d'erreurs de la proposition try originale, l'exigence de la fonction globale pour renvoyer une erreur n'est plus nécessaire.

Lorsque je me suis renseigné pour la première fois à ce sujet, l'err => panique, on m'a fait remarquer que la proposition l'envisageait mais la considérait comme trop dangereuse (pour une bonne raison). Mais si nous utilisons try() sans gestionnaire d'erreurs dans un scénario où la fonction globale ne renvoie pas d'erreur, en faire une erreur de compilation atténue le problème évoqué dans la proposition

@pjebs L'exigence de la fonction globale pour renvoyer une erreur n'était pas requise dans la conception d'origine _if_ un gestionnaire d'erreurs était fourni. Mais c'est juste une autre complication de try . C'est _beaucoup_ mieux de rester simple. Au lieu de cela, il serait plus clair d'avoir une fonction must séparée, qui panique toujours en cas d'erreur (mais sinon, c'est comme try ). Ensuite, ce qui se passe dans le code est évident et il n'est pas nécessaire de regarder le contexte.

Le principal attrait d'avoir un tel must serait qu'il pourrait être utilisé avec des tests unitaires ; surtout si le package testing a été correctement ajusté pour se remettre des paniques causées par must et les signaler comme des échecs de test d'une manière agréable. Mais pourquoi ajouter encore un autre nouveau mécanisme de langage alors que nous pouvons simplement ajuster le package de test pour accepter également la fonction de test de la forme TestXxx(t *testing.T) error ? S'ils renvoient une erreur, ce qui semble assez naturel après tout (nous aurions peut-être dû le faire dès le début), alors try fonctionnera très bien. Les tests locaux nécessiteront un peu plus de travail, mais c'est probablement faisable.

L'autre utilisation relativement courante de must est dans les expressions d'initialisation globale ( must(regexp.Compile... , etc.). Ce serait un "bien d'avoir" mais cela ne l'élève pas nécessairement au niveau requis pour une nouvelle fonctionnalité linguistique.

@griesemer Étant donné que must est vaguement lié à try , et étant donné que l'élan est vers la mise en œuvre try , ne pensez-vous pas qu'il est bon d'envisager must en même temps - même si ce n'est qu'un "bon à avoir".

Il y a de fortes chances que si ce n'est pas discuté dans ce cycle, il ne sera tout simplement pas mis en œuvre/sérieusement envisagé, au moins pendant 3 ans et plus (ou peut-être jamais). Le chevauchement des discussions serait également une bonne chose plutôt que de partir de zéro et de recycler les discussions.

Beaucoup de gens ont déclaré que must complimente très bien try .

@pjebs Il ne semble certainement pas qu'il y ait un "momentum vers la mise en œuvre try " en ce moment ... - Et nous venons également de publier cela il y a deux jours. Rien non plus n'a été décidé. Donnons-nous un peu de temps.

Il ne nous a pas échappé que must s'harmonise bien avec try , mais ce n'est pas la même chose que de l'intégrer au langage. Nous avons seulement commencé à explorer cet espace avec un groupe plus large de personnes. Nous ne savons pas encore vraiment ce qui pourrait venir en faveur ou contre. Merci.

Après avoir passé des heures à lire tous les commentaires et la documentation de conception détaillée, je voulais ajouter mon point de vue à cette proposition.

Je ferai de mon mieux pour respecter la demande de @ianlancetaylor de ne pas simplement reformuler les points précédents, mais d'ajouter à la place de nouveaux commentaires à la discussion. Cependant, je ne pense pas pouvoir faire de nouveaux commentaires sans faire référence à des commentaires antérieurs.

Préoccupations

Malheureuse surcharge de report

La préférence pour surcharger la nature évidente et simple de defer comme alarmante. Si j'écris defer closeFile(f) c'est simple et évident pour moi ce qui se passe et pourquoi ; à la fin de la fonction qui sera appelée. Et bien que l'utilisation defer pour panic() et recover() soit moins évidente, je l'utilise rarement, voire jamais, et je ne le vois presque jamais en lisant le code des autres.

Spoo pour surcharger defer pour gérer également les erreurs n'est pas évident et déroutant. Pourquoi le mot-clé defer ? Est-ce que defer ne signifie pas _"Faire plus tard"_ au lieu de _"Peut-être à plus tard ?"_

Il y a aussi la préoccupation mentionnée par l'équipe Go concernant les performances de defer . Compte tenu de cela, il semble doublement regrettable que defer soit envisagé pour le flux de code _"hot path"_.

Aucune statistique vérifiant un cas d'utilisation significatif

Comme @prologic l'a mentionné, cette proposition try() est-elle basée sur un grand pourcentage de code qui utiliserait ce cas d'utilisation, ou est-elle plutôt basée sur une tentative d'apaiser ceux qui se sont plaints de la gestion des erreurs Go ?

J'aimerais savoir comment vous donner des statistiques à partir de ma base de code sans examiner de manière exhaustive chaque fichier et prendre des notes ; Je ne sais pas comment @prologic a pu être content de l'avoir fait.

Mais pour l'anecdote, je serais surpris si try() traitait 5 % de mes cas d'utilisation et je soupçonnerais qu'il en traiterait moins de 1 %. Savez-vous avec certitude que d'autres ont des résultats très différents ? Avez-vous pris un sous-ensemble de la bibliothèque standard et essayé de voir comment il serait appliqué ?

Parce que sans statistiques connues que cela convient à un gros morceau de code dans la nature, je dois demander si ce nouveau changement compliqué du langage qui obligera tout le monde à apprendre les nouveaux concepts concerne vraiment un nombre convaincant de cas d'utilisation ?

Permet aux développeurs d'ignorer plus facilement les erreurs

C'est une répétition totale de ce que d'autres ont commenté, mais ce qui fournit fondamentalement try() est analogue à bien des égards à simplement embrasser ce qui suit comme code idomatique, et c'est un code qui ne trouvera jamais sa place dans aucun code -respecter les navires développeurs :

f, _ := os.Open(filename)

Je sais que je peux être meilleur dans mon propre code, mais je sais aussi que beaucoup d'entre nous dépendent des largesses des autres développeurs Go qui publient des packages extrêmement utiles, mais d'après ce que j'ai vu dans _"Other People's Code(tm)"_ les meilleures pratiques en matière de gestion des erreurs sont souvent ignorées.

Alors sérieusement, voulons-nous vraiment permettre aux développeurs d'ignorer plus facilement les erreurs et leur permettre de polluer GitHub avec des packages non robustes ?

Peut (principalement) déjà implémenter try() dans userland

Sauf si j'ai mal compris la proposition - ce que je fais probablement - voici try() dans le Go Playground implémenté dans userland , mais avec une seule (1) valeur de retour et renvoyant une interface au lieu du type attendu :

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]
}

Ainsi, l'utilisateur peut ajouter un try2() , try3() et ainsi de suite en fonction du nombre de valeurs de retour qu'il doit renvoyer.

Mais Go n'aurait besoin que d'une (1) fonctionnalité de langage simple _ mais universelle _ pour permettre aux utilisateurs qui veulent try() de déployer leur propre support, bien que celui-ci nécessite toujours une assertion de type explicite. Ajoutez une fonctionnalité _(entièrement rétrocompatible)_ pour un Go func afin de renvoyer un nombre variable de valeurs de retour, par exemple :

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]
}

Et si vous vous adressez d'abord aux génériques, les assertions de type ne seraient même pas nécessaires _ (bien que je pense que les cas d'utilisation des génériques devraient être réduits en ajoutant des fonctions intégrées pour traiter les cas d'utilisation des génériques plutôt que d'ajouter la sémantique confuse et la salade de syntaxe des génériques de Java et al.)_

Manque d'évidence

Lors de l'étude du code de la proposition, je trouve que le comportement n'est pas évident et quelque peu difficile à raisonner.

Lorsque je vois try() envelopper une expression, que se passe-t-il si une erreur est renvoyée ?

L'erreur sera-t-elle simplement ignorée ? Ou sautera-t-il au premier ou au plus récent defer , et si c'est le cas, définira-t-il automatiquement une variable nommée err à l'intérieur de la fermeture, ou le passera-t-il en tant que paramètre _(I ne voyez pas un paramètre ?)_. Et si ce n'est pas un nom d'erreur automatique, comment puis-je le nommer ? Et cela signifie-t-il que je ne peux pas déclarer ma propre variable err dans ma fonction, pour éviter les conflits ?

Et appellera-t-il tous les defer s ? En ordre inverse ou en ordre normal ?

Ou reviendra-t-il à la fois de la fermeture et du func où l'erreur a été renvoyée ? _(Quelque chose que je n'aurais jamais envisagé si je n'avais pas lu ici des mots qui impliquent cela.)_

Après avoir lu la proposition et tous les commentaires jusqu'à présent, honnêtement, je ne connais toujours pas les réponses aux questions ci-dessus. Est-ce le genre de fonctionnalité que nous voulons ajouter à un langage dont les défenseurs sont _"Captain Obvious?"_

Manque de contrôle

En utilisant defer , il semble que le seul contrôle que les développeurs auraient les moyens est de se brancher sur _(le plus récent ?)_ defer . Mais d'après mon expérience avec toutes les méthodes au-delà d'un trivial func , c'est généralement plus compliqué que cela.

Souvent, j'ai trouvé utile de partager l'aspect de la gestion des erreurs dans un func - ou même sur un package - mais aussi d'avoir une gestion plus spécifique partagée entre un ou plusieurs autres packages.

Par exemple, je peux appeler cinq (5) appels func qui renvoient un error() depuis un autre func ; étiquetons-les A() , B() , C() , D() et E() . J'ai peut-être besoin C() pour avoir sa propre gestion des erreurs, A() , B() , D() et E() pour partager une gestion des erreurs, et B() et E() pour avoir un traitement spécifique.

Mais je ne crois pas qu'il serait possible de le faire avec cette proposition. Du moins pas facilement.

Ironiquement, cependant, Go possède déjà des fonctionnalités de langage qui permettent un haut niveau de flexibilité qui n'a pas besoin d'être limité à un petit ensemble de cas d'utilisation ; func s et fermetures. Donc ma question rhétorique est :

_ "Pourquoi ne pouvons-nous pas simplement ajouter de légères améliorations au langage existant pour répondre à ces cas d'utilisation et ne pas avoir besoin d'ajouter de nouvelles fonctions intégrées ou d'accepter une sémantique confuse ?" _

C'est une question rhétorique car j'ai l'intention de soumettre une proposition alternative, celle que j'ai conçue lors de l'étude de cette proposition et en considérant tous ses inconvénients.

Mais je m'égare, cela viendra plus tard et ce commentaire explique pourquoi la proposition actuelle doit être réexaminée.

Absence de soutien déclaré pour break

Cela peut sembler sortir du champ gauche car la plupart des gens utilisent les premiers retours pour la gestion des erreurs, mais j'ai trouvé qu'il est préférable d'utiliser break pour la gestion des erreurs en enveloppant la plupart ou la totalité d'une fonction avant return .

J'utilise cette approche depuis un certain temps et ses avantages pour faciliter la refactorisation la rendent préférable à return précoce, mais elle présente plusieurs autres avantages, notamment un point de sortie unique et la possibilité de terminer une section d'une fonction plus tôt mais toujours être capable d'exécuter le nettoyage _ (ce qui est probablement la raison pour laquelle j'utilise si rarement defer , ce sur quoi je trouve plus difficile de raisonner en termes de déroulement du programme.)_

Pour utiliser break au lieu d'un retour anticipé, utilisez une boucle for range "1" {...} pour créer un bloc permettant à la pause de sortir de _ (je crée en fait un package appelé only qui ne contient qu'une constante appelé Once avec une valeur de "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
}

Je prévois de bloguer longuement sur le modèle dans un avenir proche et de discuter des nombreuses raisons pour lesquelles j'ai trouvé qu'il fonctionnait mieux que les premiers retours.

Mais je m'égare. Ma raison de l'évoquer ici est que je devrais pour Go mettre en œuvre une gestion des erreurs qui suppose au début return s et ignore l'utilisation break pour la gestion des erreurs

Mon avis err == nil est problématique

Comme digression supplémentaire, je veux évoquer le souci que j'ai ressenti à propos de la gestion des erreurs idiomatiques dans Go. Bien que je sois un fervent partisan de la philosophie de Go pour gérer les erreurs lorsqu'elles se produisent par rapport à l'utilisation de la gestion des exceptions, je pense que l'utilisation de nil pour indiquer qu'aucune erreur n'est problématique car je trouve souvent que je voudrais renvoyer un message de réussite de une routine - à utiliser dans les réponses de l'API - et ne renvoie pas seulement une valeur non nulle juste en cas d'erreur.

Donc, pour Go 2, j'aimerais vraiment voir Go envisager d'ajouter un nouveau type intégré de status et trois fonctions intégrées iserror() , iswarning() , issuccess() . status pourrait implémenter error — permettant une grande rétrocompatibilité et une nil passée à issuccess() renverrait true — mais status aurait un état interne supplémentaire pour le niveau d'erreur afin que le test du niveau d'erreur soit toujours effectué avec l'une des fonctions intégrées et idéalement jamais avec une vérification nil . Cela permettrait plutôt quelque chose comme l'approche suivante :

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
}

J'utilise déjà une approche utilisateur dans un package à usage interne de niveau pré-bêta qui est similaire à ce qui précède pour la gestion des erreurs. Franchement , je passe beaucoup moins de temps à réfléchir à la façon de structurer le code lorsque j'utilise cette approche que lorsque j'essayais de suivre la gestion idiomatique des erreurs Go.

Si vous pensez qu'il est possible de faire évoluer le code Go idiomatique vers cette approche, veuillez en tenir compte lors de la mise en œuvre de la gestion des erreurs, y compris lors de l'examen de cette proposition try() .

_"Pas pour tout le monde"_ justification

L'une des principales réponses de l'équipe Go a été _"Encore une fois, cette proposition ne tente pas de résoudre toutes les situations de gestion des erreurs."_
Et c'est probablement la préoccupation la plus troublante, du point de vue de la gouvernance.

Cette nouvelle modification complexe du langage qui obligera tout le monde à apprendre les nouveaux concepts concerne-t-elle vraiment un nombre convaincant de cas d'utilisation ?

Et n'est-ce pas la même justification que les membres de l'équipe principale ont refusé de nombreuses demandes de fonctionnalités de la part de la communauté ? Ce qui suit est une citation directe d'un commentaire fait par un membre de l'équipe Go dans une réponse archétypique à une demande de fonctionnalité soumise il y a environ 2 ans _ (je ne nomme pas la personne ou la demande de fonctionnalité spécifique car cette discussion ne devrait pas pouvoir les gens mais plutôt sur la langue):_

_"Une nouvelle fonctionnalité de langage a besoin de cas d'utilisation convaincants. Toutes les fonctionnalités de langage sont utiles, sinon personne ne les proposerait ; la question est : sont-elles suffisamment utiles pour justifier de compliquer le langage et d'obliger tout le monde à apprendre les nouveaux concepts ? ici ? Comment les gens les utiliseront-ils ? Par exemple, les gens s'attendraient-ils à pouvoir... et si oui, comment feraient-ils cela ? Cette proposition fait-elle plus que vous permettre...?"_
— Un membre principal de l'équipe Go

Franchement, quand j'ai vu ces réponses, j'ai ressenti l'un des deux sentiments suivants :

1. Indignation s'il s'agit d'une caractéristique avec laquelle je suis d'accord, ou
2. Exaltation si c'est une caractéristique avec laquelle je ne suis pas d'accord.

Mais dans les deux cas, mes sentiments étaient/sont hors de propos ; Je comprends et je suis d'accord qu'une partie de la raison pour laquelle Go est la langue dans laquelle tant d'entre nous choisissent de se développer est à cause de cette garde jalouse de la pureté de la langue.

Et c'est pourquoi cette proposition me trouble tellement, parce que l'équipe principale de Go semble approfondir cette proposition au même niveau que quelqu'un qui veut dogmatiquement une fonctionnalité ésotérique qu'il n'y a aucun moyen que la communauté Go tolère jamais.

_(Et j'espère vraiment que l'équipe ne tirera pas sur le messager et ne prendra pas cela comme une critique constructive de la part de quelqu'un qui veut voir Go continuer à être le meilleur possible pour nous tous car je devrais être considéré comme "Persona non grata" par l'équipe de base.)_

Si l'exigence d'un ensemble convaincant de cas d'utilisation réels est la barre pour toutes les propositions de fonctionnalités générées par la communauté, ne devrait-elle pas également être la même pour _ toutes _ les propositions de fonctionnalités ?

Imbrication de try()

Cela aussi a été couvert par quelques-uns, mais je veux établir une comparaison entre try() et la demande continue d'opérateurs ternaires. Citant les commentaires d'un autre membre de l'équipe Go il y a environ 18 mois :

_"lors de la "programmation à grande échelle" (grandes bases de code avec de grandes équipes sur de longues périodes), le code est lu BEAUCOUP plus souvent qu'il n'est écrit, nous optimisons donc la lisibilité, pas l'écriture."_

L'une des _principales_ raisons invoquées pour ne pas ajouter d'opérateurs ternaires est qu'ils sont difficiles à lire et/ou faciles à mal lire lorsqu'ils sont imbriqués. Pourtant, la même chose peut être vraie pour les instructions try() imbriquées comme try(try(try(to()).parse().this)).easily()) .

Des raisons supplémentaires pour argumenter contre les opérateurs ternaires ont été qu'ils sont des _"expressions"_ avec cet argument que les expressions imbriquées peuvent ajouter de la complexité. Mais try() ne crée-t-il pas aussi une expression emboîtable ?

Maintenant, quelqu'un ici a dit _"Je pense que des exemples comme [ try() s imbriqués] sont irréalistes"_ et cette affirmation n'a pas été contestée.

Mais si les gens acceptent comme postulat que les développeurs n'imbriqueront pas try() alors pourquoi la même déférence n'est-elle pas accordée aux opérateurs ternaires quand les gens disent _"Je pense que les opérateurs ternaires profondément imbriqués sont irréalistes?"_

En bout de ligne pour ce point, je pense que si l'argument contre les opérateurs ternaires est vraiment valable, alors ils devraient également être considérés comme des arguments valables contre cette proposition try() .

En résumé

Au moment d'écrire ces lignes, les votes contre $ 58% contre 42% votent pour. Je pense que cela seul devrait suffire à indiquer qu'il s'agit d'une proposition suffisamment controversée pour qu'il soit temps de revenir à la planche à dessin sur cette question.

fwiw

PS Pour le dire plus ironiquement, je pense que nous devrions suivre la sagesse paraphrasée de Yoda :

_"Il n'y a pas try() . Seulement do() ."_

@ianlancetaylor

@beoran Vous pourriez peut-être développer le lien entre les génériques et la gestion des erreurs.

Je ne parle pas pour @beoran mais dans mon commentaire d'il y a quelques minutes, vous verrez que si nous avions des génériques _(plus des paramètres de retour variadic)_ alors nous pourrions construire notre propre try() .

Cependant — et je vais répéter ce que j'ai dit plus haut à propos des génériques ici où il sera plus facile de voir :

_"Je pense que les cas d'utilisation des génériques devraient être réduits en ajoutant des éléments intégrés pour traiter les cas d'utilisation des génériques plutôt que d'ajouter la sémantique confuse et la salade de syntaxe des génériques de Java et al.)"_

@ianlancetaylor

En essayant de formuler une réponse à votre question, j'ai essayé d'implémenter la fonction try dans Go telle quelle, et à mon grand plaisir, il est en fait déjà possible d'émuler quelque chose d'assez similaire :

func try(v interface{}, err error) interface{} {
   if err != nil { 
     panic(err)
   }
   return v
}

Voyez ici comment il peut être utilisé : https://play.golang.org/p/Kq9Q0hZHlXL

Les inconvénients de cette approche sont :

1. Un sauvetage différé est nécessaire, mais avec try comme dans cette proposition, un gestionnaire différé est également nécessaire si nous voulons gérer correctement les erreurs. Donc, je pense que ce n'est pas un inconvénient grave. Cela pourrait même être mieux si Go avait une sorte de super(arg1, ..., argn) intégré qui fait que l'appelant de l'appelant, un niveau supérieur dans la pile des appels, retourne avec les arguments donnés arg1,...argn, une sorte de super retour si vous voulez.
2. Ce try que j'ai implémenté ne peut fonctionner qu'avec une fonction qui renvoie un seul résultat et une erreur.
3. Vous devez taper assert les résultats de l'interface vide renvoyés.

Des génériques suffisamment puissants pourraient résoudre les problèmes 2 et 3, en laissant seulement 1, qui pourrait être résolu en ajoutant un super() . Avec ces deux fonctionnalités en place, nous pourrions obtenir quelque chose comme :

func (T ... interface{})try(T, err error) super {
   if err != nil { 
      super(err)
   }
  super(T...)
}

Et alors le sauvetage différé ne serait plus nécessaire. Cet avantage serait disponible même si aucun générique n'est ajouté à Go.

En fait, cette idée d'un super() intégré est si puissante et intéressante que je pourrais poster une proposition séparément.

@beoran C'est bien de voir que nous sommes arrivés à exactement les mêmes contraintes indépendamment concernant l'implémentation try() dans userland, à l'exception de la super partie que je n'ai pas incluse parce que je voulais parler de quelque chose de similaire dans une proposition alternative. :-)

J'aime la proposition, mais le fait que vous deviez spécifier explicitement que defer try(...) et go try(...) ne sont pas autorisés m'a fait penser que quelque chose n'allait pas... L'orthogonalité est un bon guide de conception. En lisant plus loin et en voyant des choses comme
x = try(foo(...)) y = try(bar(...))
Je me demande si try doit être un contexte ! Considérer:
try ( x = foo(...) y = bar(...) )
Ici, foo() et bar() renvoient deux valeurs, dont la seconde est error . La sémantique d'essai n'a d'importance que pour les appels dans le bloc try où la valeur d'erreur renvoyée est élidée (pas de récepteur) et non ignorée (le récepteur est _ ). Vous pouvez même gérer certaines erreurs entre les appels foo et bar .

Sommaire:
a) le problème d'interdiction de try pour go et defer disparaît grâce à la syntaxe.
b) la gestion des erreurs de plusieurs fonctions peut être factorisée.
c) sa nature magique est mieux exprimée par une syntaxe spéciale que par un appel de fonction.

Si try est un contexte, nous venons de créer des blocs try/catch que nous essayons spécifiquement d'éviter (et pour une bonne raison)

Il n'y a pas de piège. Exactement le même code serait généré que lorsque la proposition actuelle a
x = try(foo(...)) y = try(bar(...))
C'est juste une syntaxe différente, pas une sémantique.
````

Je suppose que j'avais fait quelques hypothèses à ce sujet que je n'aurais pas dû faire, bien qu'il y ait encore quelques inconvénients.

Que se passe-t-il si foo ou bar ne renvoient pas d'erreur, peuvent-ils également être placés dans le contexte try ? Sinon, cela semble être un peu moche de basculer entre les fonctions d'erreur et de non-erreur, et si elles le peuvent, alors nous retombons sur les problèmes de blocs try dans les langages plus anciens.

La deuxième chose est que, typiquement, la syntaxe keyword ( ... ) signifie que vous préfixez le mot-clé sur chaque ligne. Donc pour import, var, const, etc : chaque ligne commence par le mot clé. Faire une exception à cette règle ne semble pas être une bonne décision

Au lieu d'utiliser une fonction, serait-il simplement plus idiomatique d'utiliser un identifiant spécial ?

Nous avons déjà l'identifiant vide _ qui ignore les valeurs.
Nous pourrions avoir quelque chose comme # qui ne peut être utilisé que dans les fonctions qui ont la dernière valeur renvoyée de type error.

func foo() (error) {
    f, # := os.Open()
    defer f.Close()
    _, # = f.WriteString("foo")
    return nil
}

lorsqu'une erreur est affectée à # la fonction retourne immédiatement avec l'erreur reçue. Quant aux autres variables, leurs valeurs seraient :

• s'ils ne sont pas nommés valeur zéro
• la valeur attribuée aux variables nommées sinon

@deanveloper , la sémantique du bloc try n'a d'importance que pour les fonctions qui renvoient une valeur d'erreur et où la valeur d'erreur n'est pas affectée. Ainsi, le dernier exemple de la proposition actuelle pourrait également être écrit comme
try(x = foo(...)) try(y = bar(...))
mettre les deux instructions dans le même bloc est similaire à ce que nous faisons pour les instructions répétées import , const et var .

Maintenant, si vous avez, par exemple
try( x = foo(...)) go zee(...) defer fum() y = bar(...) )
Cela équivaut à écrire
try(x = foo(...)) go zee(...) defer fum() try(y = bar(...))
La factorisation de tout cela dans un bloc d'essai le rend moins occupé.

Considérer
try(x = foo())
Si foo() ne renvoie pas de valeur d'erreur, cela équivaut à
x = foo()

Considérer
try(f, _ := os.open(filename))
Étant donné que la valeur d'erreur renvoyée est ignorée, cela équivaut à juste
f, _ := os.open(filename)

Considérer
try(f, err := os.open(filename))
Étant donné que la valeur d'erreur renvoyée n'est pas ignorée, cela équivaut à
f, err := os.open(filename) if err != nil { return ..., err }
Tel qu'il est actuellement spécifié dans la proposition.

Et cela désencombre également les essais imbriqués !

Voici un lien vers la proposition alternative que j'ai mentionnée ci-dessus :

• https://github.com/golang/go/issues/32473

Il appelle à l'ajout de deux (2) fonctionnalités de langage petites mais à usage général pour traiter les mêmes cas d'utilisation que try()

1. Possibilité d'appeler un func /closing dans une instruction d'affectation.
2. Possibilité de break , continue ou return plus d'un niveau.

Avec ces deux fonctionnalités, ce ne serait pas _"magique"_ et je pense que leur utilisation produirait un code Go plus facile à comprendre et plus conforme au code Go idiomatique que nous connaissons tous.

J'ai lu la proposition et j'aime vraiment où essayer va.

Étant donné la prévalence de l'essai, je me demande si en faire un comportement par défaut le rendrait plus facile à gérer.

Pensez aux cartes. C'est valable :

v := m[key]

tel quel:

v, ok := m[key]

Et si nous gérons les erreurs exactement comme try le suggère, mais supprimons le fichier intégré. Donc si on commençait par :

v, err := fn()

Au lieu d'écrire :

v := try(fn())

On pourrait plutôt écrire :

v := fn()

Lorsque la valeur err n'est pas capturée, elle est gérée exactement comme try. Il faudrait un peu de temps pour s'y habituer, mais cela ressemble beaucoup à v, ok := m[key] et v, ok := x.(string) . Fondamentalement, toute erreur non gérée entraîne le retour de la fonction et la définition de la valeur err.

Pour revenir aux conclusions des documents de conception et aux exigences de mise en œuvre :

• La syntaxe du langage est conservée et aucun nouveau mot-clé n'est introduit
• Cela continue d'être du sucre syntaxique comme try et, espérons-le, c'est facile à expliquer.
• Ne nécessite pas de nouvelle syntaxe
• Il doit être entièrement compatible avec les versions antérieures.

J'imagine que cela aurait à peu près les mêmes exigences de mise en œuvre que try car la principale différence est plutôt que le déclenchement intégré du sucre syntaxique, maintenant c'est l'absence du champ err.

Donc, en utilisant l'exemple CopyFile de la proposition avec defer fmt.HandleErrorf(&err, "copy %s %s", src, dst) , nous obtenons :

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 J'aime ça et je pensais à ce qu'il faudrait pour que Go retourne la gestion des erreurs en gérant toujours les erreurs par défaut et en laissant le programmeur spécifier quand ne pas le faire (en capturant l'erreur dans une variable) mais absence totale de tout l'identifiant rendrait le code difficile à suivre car on ne pourrait pas voir tous les points de retour. Peut-être qu'une convention pour nommer les fonctions qui pourraient renvoyer une erreur différemment pourrait fonctionner (comme la capitalisation des identifiants publics). Peut-être que si une fonction renvoie une erreur, elle doit toujours se terminer par, disons ? . Ensuite, Go pourrait toujours gérer implicitement l'erreur et la renvoyer automatiquement à la fonction appelante, tout comme try. Cela le rend très similaire à certaines propositions suggérant d'utiliser un identifiant ? au lieu d'essayer, mais une différence importante est qu'ici ? ferait partie du nom de la fonction et non un identifiant supplémentaire. En fait, une fonction qui renvoyait error comme dernière valeur de retour ne serait même pas compilée si elle n'était pas suffixée ? . Bien sûr, ? est arbitraire et pourrait être remplacé par n'importe quoi d'autre qui rendrait l'intention plus explicite. operation?() équivaudrait à envelopper try(someFunc()) mais ? ferait partie du nom de la fonction et son seul but serait d'indiquer que la fonction peut renvoyer une erreur tout comme la mise en majuscule la première lettre d'une variable.

Cela finit par être très similaire à d'autres propositions demandant de remplacer try par ? mais une différence critique est que la gestion des erreurs est implicite (automatique) et rend à la place explicite les erreurs d'ignorance (ou d'emballage) qui une sorte de meilleure pratique de toute façon. Le problème le plus évident avec cela est bien sûr qu'il n'est pas rétrocompatible et je suis sûr qu'il y en a beaucoup d'autres.

Cela dit, je serais très intéressé de voir comment Go peut gérer les erreurs de cas par défaut/implicite en l'automatisant et laisser le programmeur écrire un peu de code supplémentaire pour ignorer/remplacer la gestion. Je pense que le défi est de savoir comment rendre tous les points de retour évidents dans ce cas, car sans cela, les erreurs deviendront plus comme des exceptions dans le sens où elles pourraient provenir de n'importe où car le déroulement du programme ne le rendrait pas évident. On pourrait dire que faire des erreurs implicites avec un indicateur visuel revient à implémenter try et à faire errcheck un échec du compilateur.

pourrions-nous faire quelque chose comme des exceptions c++ avec des décorateurs pour les anciennes fonctions ?

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 Je pensais que la sémantique serait exactement la même que try donc au moins vous auriez besoin de déclarer le type err. Donc si on commençait par :

func foo() error {
  _, err := fn() 
  if err != nil {
    return err
  }

  return nil
} 

Si je comprends la proposition d'essai, faites simplement ceci:

func foo() error {
  _  := fn() 
  return nil
} 

ne compilerait pas. Un avantage intéressant est que cela donne à la compilation l'opportunité de dire à l'utilisateur ce qui manque. Quelque chose à l'effet que l'utilisation de la gestion implicite des erreurs nécessite que le type de retour d'erreur soit nommé, err.

Cela fonctionnerait alors:

func foo() (err error) {
  _  := fn() 
  return nil
} 

pourquoi ne pas simplement gérer le cas d'une erreur qui n'est pas affectée à une variable.

• supprimez le besoin de retours nommés, le compilateur peut le faire tout seul.
• permet d'ajouter du contexte.
• gère le cas d'utilisation courant.
• rétrocompatible
• n'interagit pas bizarrement avec le report, les boucles ou les commutateurs.

retour implicite pour le cas if err != nil, le compilateur peut générer un nom de variable locale pour les retours si nécessaire inaccessible au programmeur.
personnellement, je n'aime pas ce cas particulier du point de vue de la lisibilité du code

f := os.Open("foo.txt")

préfère un retour explicite, suit le code est lu plus qu'un mantra écrit

f := os.Open("foo.txt") else return

fait intéressant, nous pourrions accepter les deux formes et demander à gofmt d'ajouter automatiquement le retour else.

ajout de contexte, également nommage local de la variable. return devient explicite car nous voulons ajouter du contexte.

f := os.Open("foo.txt") else err {
  return errors.Wrap(err, "some context")
}

ajouter du contexte avec plusieurs valeurs de retour

f := os.Open("foo.txt") else err {
  return i, j, errors.Wrap(err, "some context")
}

les fonctions imbriquées nécessitent que les fonctions externes traitent tous les résultats dans le même ordre
moins l'erreur finale.

bits := ioutil.ReadAll(os.Open("foo")) else err {
  // either error ends up here.
  return i, j, errors.Wrap(err, "some context")
}

le compilateur refuse la compilation en raison d'une valeur de retour d'erreur manquante dans la fonction

func foo(s string) int {
   i := strconv.Atoi(s) // cannot implicitly return error due to missing error return value for foo.
   return i * 2
}

se compile avec bonheur car l'erreur est explicitement ignorée.

func foo(s string) int {
   i, _ := strconv.Atoi(s)
   return i * 2
} 

le compilateur est content. il ignore l'erreur comme il le fait actuellement car aucune affectation ou autre suffixe ne se produit.

func foo() error {
  return errors.New("whoops")
}

func bar() {
  foo()
}

dans une boucle, vous pouvez utiliser continue.

for _, s := range []string{"1","2","3","4","5","6"} {
  i := strconv.Atoi(s) else continue
}

edit : remplacé ; par else

@savaki Je pense avoir compris votre commentaire d'origine et j'aime l'idée que Go gère les erreurs par défaut, mais je ne pense pas que ce soit viable sans ajouter quelques modifications de syntaxe supplémentaires et une fois que nous l'avons fait, cela devient étonnamment similaire à la proposition actuelle.

Le plus gros inconvénient de ce que vous proposez est qu'il n'expose pas tous les points à partir desquels une fonction peut revenir contrairement à l'actuel if err != nil {return err} ou à la fonction try introduite dans cette proposition. Même s'il fonctionnerait exactement de la même manière sous le capot, visuellement, le code serait très différent. Lors de la lecture du code, il n'y aurait aucun moyen de savoir quels appels de fonction pourraient renvoyer une erreur. Cela finirait par être une expérience pire que les exceptions IMO.

Peut-être que la gestion des erreurs pourrait être rendue implicite si le compilateur imposait une convention sémantique sur les fonctions susceptibles de renvoyer des erreurs. Comme s'ils devaient commencer ou se terminer par une certaine phrase ou un certain caractère. Cela rendrait tous les points de retour très évidents et je pense que ce serait mieux que la gestion manuelle des erreurs, mais je ne sais pas à quel point c'est mieux étant donné qu'il existe déjà des contrôles de charpie qui crient lorsqu'ils repèrent une erreur ignorée. Il serait très intéressant de voir si le compilateur peut forcer les fonctions à être nommées d'une certaine manière selon qu'elles peuvent renvoyer d'éventuelles erreurs.

Le principal inconvénient de cette approche est que le paramètre de résultat d'erreur doit être nommé, ce qui peut conduire à des API moins jolies (mais voir la FAQ à ce sujet). Nous pensons que nous nous y habituerons une fois que ce style se sera imposé.

Je ne sais pas si quelque chose comme ça a déjà été suggéré, je ne le trouve pas ici ou dans la proposition. Avez-vous envisagé une autre fonction intégrée qui renvoie un pointeur vers la valeur de retour d'erreur de la fonction actuelle ?
par exemple:

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")
}

utilisation avec try:

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
}

Alternativement funcerror (le nom est un travail en cours :D ) pourrait retourner nil s'il n'est pas appelé à l'intérieur de defer.

Une autre alternative est que funcerror renvoie une interface "Errorer" pour la rendre en lecture seule :

type interface Errorer() {
        Error() error
}

@savaki En fait, j'aime bien votre proposition d'omettre try() et de lui permettre de ressembler davantage à un test de carte ou à une assertion de type. Cela ressemble beaucoup plus à _"Go-like."_

Cependant, il y a toujours un problème flagrant que je vois, et c'est que votre proposition suppose que toutes les erreurs utilisant cette approche déclencheront un return et quitteront la fonction. Ce qu'il n'envisage pas, c'est d'émettre un break sur les for actuels ou un continue pour les for actuels.

Les premiers return s sont un marteau de forgeron alors qu'un scalpel est souvent le meilleur choix.

Donc, j'affirme que break et continue devraient être autorisés à être des stratégies de gestion des erreurs valides et actuellement votre proposition ne suppose que return alors que try() suppose que ou appelle une erreur gestionnaire qui lui-même ne peut que return , pas break ou continue .

On dirait que savaki et moi avons eu des idées similaires, j'ai juste ajouté la sémantique de bloc pour traiter l'erreur si vous le souhaitez. Par exemple, ajouter du texte, des boucles où vous voulez court-circuiter, etc.

@mikeschinkel voir mon extension, lui et moi avions des idées similaires, je viens de l'étendre avec une instruction de bloc facultative

@james-lawrence

@mikesckinkel voir mon extension, lui et moi avions des idées similaires, je viens de l'étendre avec une instruction de bloc facultative

Prenant ton exemple :

f := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

Ce qui se compare à ce que nous faisons aujourd'hui :

f,err := os.Open("foo.txt"); 
if err != nil {
  return errors.Wrap(err, "some context")
}

M'est définitivement préférable. Sauf qu'il a quelques problèmes :

1. err semble être _"magiquement"_ déclaré. La magie devrait être minimisée, non ? Alors déclarons-le :

f, err := os.Open("foo.txt"); err {
  return errors.Wrap(err, "some context")
}

1. Mais cela ne fonctionne toujours pas car Go n'interprète pas les valeurs nil comme false ni les valeurs de pointeur comme true , il faudrait donc:

f, err := os.Open("foo.txt"); err != nil {
  return errors.Wrap(err, "some context")
}

Et ce que cela fonctionne, cela commence à ressembler à autant de travail et à beaucoup de syntaxe sur une seule ligne, donc et je pourrais continuer à faire à l'ancienne pour plus de clarté.

Mais que se passerait-il si Go ajoutait deux (2) commandes intégrées ; iserror() et error() ? Ensuite, nous pourrions faire ceci, ce qui ne me semble pas si mal :

f := os.Open("foo.txt"); iserror() {
  return errors.Wrap(error(), "some context")
}

Ou mieux _(quelque chose comme):_

f := os.Open("foo.txt"); iserror() {
  return error().Extend("some context")
}

Qu'en pensez-vous, et les autres ?

En aparté, vérifiez l'orthographe de mon nom d'utilisateur. Je n'aurais pas été informé de votre mention si je n'avais pas fait attention de toute façon...

@mikeschinkel désolé pour le nom que j'avais sur mon téléphone et github ne suggérait pas automatiquement.

err semble être "magiquement" déclaré. La magie devrait être minimisée, non ? Alors déclarons-le :

meh, toute l'idée d'insérer automatiquement un retour est magique. ce n'est pas la chose la plus magique qui se passe dans toute cette proposition. De plus, je dirais que l'erreur a été déclarée ; juste à la fin dans le contexte d'un bloc de portée, l'empêchant de polluer la portée parent tout en conservant toutes les bonnes choses que nous obtenons normalement avec l'utilisation des instructions if.

Je suis généralement assez satisfait de la gestion des erreurs de go avec les ajouts à venir au package d'erreurs. Je ne vois rien dans cette proposition comme super utile. J'essaie juste d'offrir l'ajustement le plus naturel pour le golang si nous sommes déterminés à le faire.

_"l'idée même d'insérer automatiquement un retour est magique."_

Vous n'obtiendrez aucun argument de ma part là-bas.

_"Ce n'est pas la chose la plus magique qui se passe dans toute cette proposition."_

Je suppose que j'essayais de dire que _"toute magie est problématique."_

_"De plus, je dirais que l'erreur a été déclarée ; juste à la fin dans le contexte d'un bloc de portée..."_

Donc, si je voulais l'appeler err2 , cela fonctionnerait aussi ?

f := os.Open("foo.txt"); err2 {
  return errors.Wrap(err, "some context")
}

Je suppose donc que vous proposez également une gestion spéciale des cas de err / err2 après le point-virgule, c'est-à-dire qu'il serait supposé être nil ou non nil au lieu de bool comme lors de la vérification d'une carte ?

if _,ok := m[a]; !ok {
   print("there is no 'a' in 'm'")
}

Je suis généralement assez satisfait de la gestion des erreurs de go avec les ajouts à venir au package d'erreurs.

Moi aussi, je suis satisfait de la gestion des erreurs, lorsqu'elle est combinée avec break et continue _ (mais pas return .)_

Dans l'état actuel des choses, je considère cette proposition de try() comme plus nuisible qu'utile, et je préférerais ne rien voir que cette mise en œuvre telle que proposée. #jmtcw.

@beoran @mikeschinkel Plus tôt, j'ai suggéré que nous ne pouvions pas implémenter cette version de try en utilisant des génériques, car cela modifie le flux de contrôle. Si je lis correctement, vous suggérez tous les deux que nous pourrions utiliser des génériques pour implémenter try en le faisant appeler panic . Mais cette version de try très explicitement ne fait pas panic . Nous ne pouvons donc pas utiliser de génériques pour implémenter cette version de try .

Oui, nous pourrions utiliser des génériques (une version des génériques nettement plus puissante que celle du brouillon de conception sur https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md) pour écrire une fonction qui panique en cas d'erreur. Mais paniquer en cas d'erreur n'est pas le genre de gestion d'erreurs que les programmeurs Go écrivent aujourd'hui, et cela ne me semble pas être une bonne idée.

@mikeschinkel une gestion spéciale serait que le bloc ne s'exécute qu'en cas d'erreur.
```
f := os.Open('foo'); err { return err } // err serait toujours non nul ici.

@ianlancetaylor

_"Oui, nous pourrions utiliser des génériques... Mais paniquer en cas d'erreur n'est pas le genre de gestion d'erreurs que les programmeurs Go écrivent aujourd'hui, et cela ne me semble pas être une bonne idée."_

En fait, je suis fortement d'accord avec vous sur ce point, il semble donc que vous ayez mal interprété l'intention de mon commentaire. Je ne suggérais pas du tout que l'équipe Go mettrait en œuvre une gestion des erreurs utilisant panic() - bien sûr que non.

Au lieu de cela, j'essayais de suivre votre exemple à partir de bon nombre de vos commentaires passés sur d'autres problèmes et j'ai suggéré que nous évitions d'apporter à Go des modifications qui ne sont pas absolument nécessaires, car elles sont plutôt possibles dans userland . Donc _si_ les génériques étaient adressés _alors_ les personnes qui voudraient try() pourraient en fait l'implémenter elles-mêmes, mais en tirant parti panic() . Et ce serait une fonctionnalité de moins que l'équipe aurait besoin d'ajouter et de documenter pour Go.

Ce que je ne faisais pas - et peut-être que ce n'était pas clair - préconisait que les gens utilisent réellement panic() pour implémenter try() , juste qu'ils le pouvaient s'ils le voulaient vraiment, et ils avaient les fonctionnalités de génériques.

Est-ce que cela clarifie?

Pour moi, appeler panic , quelle que soit la façon dont cela est fait, est assez différent de cette proposition pour try . Donc, bien que je pense comprendre ce que vous dites, je ne suis pas d'accord pour dire qu'ils sont équivalents. Même si nous avions des génériques suffisamment puissants pour implémenter une version de try qui panique, je pense qu'il y aurait toujours un désir raisonnable pour la version de try présentée dans cette proposition.

@ianlancetaylor Reconnu. Encore une fois, je cherchais une raison pour laquelle try() n'aurait pas besoin d'être ajouté plutôt que de trouver un moyen de l'ajouter. Comme je l'ai dit plus haut, je préférerais de loin ne rien avoir de nouveau pour la gestion des erreurs que d'avoir try() comme proposé ici.

Personnellement, j'aimais plus la proposition précédente check , basée sur des aspects purement visuels ; check avait la même puissance que ce try() mais bar(check foo()) est plus lisible pour moi que bar(try(foo())) (j'ai juste eu besoin d'une seconde pour compter les parenthèses !).

Plus important encore, mon principal reproche à propos handle / check était qu'il ne permettait pas d'envelopper des chèques individuels de différentes manières - et maintenant cette proposition try() a le même défaut, tout en invoquant des fonctionnalités délicates, rarement utilisées et déroutantes pour les débutants, des reports et des retours nommés. Et avec handle au moins, nous avions la possibilité d'utiliser des portées pour définir des blocs de poignée, avec defer même cela n'est pas possible.

En ce qui me concerne, cette proposition perd à la proposition précédente handle / check à tous égards.

Voici un autre problème lié à l'utilisation de reports pour la gestion des erreurs.

try est une sortie contrôlée/intentionnelle d'une fonction. reporte toujours l'exécution, y compris les sorties incontrôlées/involontaires des fonctions. Cette incompatibilité pourrait prêter à confusion. Voici un scénario imaginaire :

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
}

Rappelez-vous que net/http récupère des paniques et imaginez le débogage d'un problème de production autour de la panique. Vous regarderiez votre instrumentation et verriez un pic d'échecs d'appels db, à partir des appels recordMetric . Cela pourrait masquer le vrai problème, qui est la panique dans la ligne suivante.

Je ne sais pas à quel point cela est grave dans la pratique, mais c'est (malheureusement) peut-être une autre raison de penser que le report n'est pas un mécanisme idéal pour la gestion des erreurs.

Voici une modification qui peut aider à résoudre certains des problèmes soulevés : traitez try comme un goto au lieu de comme un return . Écoutez-moi. :)

try serait plutôt du sucre syntaxique pour :

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

Avantages:

• defer n'est pas nécessaire pour décorer les erreurs. (Les retours nommés sont toujours requis, cependant.)
• L'existence de l'étiquette error: est un indice visuel qu'il y a un try quelque part dans la fonction.

Cela fournit également un mécanisme pour ajouter des gestionnaires qui contourne les problèmes de gestionnaire en tant que fonction : Utilisez des étiquettes comme gestionnaires. try(fn(), wrap) donnerait goto wrap au lieu de goto error . Le compilateur peut confirmer que wrap: est présent dans la fonction. Notez que le fait d'avoir des gestionnaires aide également au débogage : vous pouvez ajouter/modifier le gestionnaire pour fournir un chemin de débogage.

Exemple de code :

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)
}

Autres commentaires:

• Nous pourrions exiger que toute étiquette utilisée comme cible d'un try soit précédée d'une instruction de fin. En pratique, cela les forcerait à la fin de la fonction et pourrait empêcher certains codes spaghetti. D'un autre côté, cela pourrait empêcher certaines utilisations raisonnables et utiles.
• try pourrait être utilisé pour créer une boucle. Je pense que cela relève de la bannière "si ça fait mal, ne le fais pas", mais je n'en suis pas sûr.
• Cela nécessiterait de corriger https://github.com/golang/go/issues/26058.

Crédit : Je crois qu'une variante de cette idée a été suggérée pour la première fois par @griesemer en personne à GopherCon l'année dernière.

@josharian Penser à l'interaction avec panic est important ici, et je suis content que vous en ayez parlé, mais votre exemple me semble étrange. Dans le code suivant, cela n'a pas de sens pour moi que le report enregistre toujours une métrique "db call failed" . Ce serait une fausse métrique si someHTTPHandlerGuts réussit et renvoie nil . Le defer s'exécute dans tous les cas de sortie, pas seulement dans les cas d'erreur ou de panique, de sorte que le code semble erroné même s'il n'y a pas de panique.

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 Oui, c'est plus ou moins exactement la version dont nous avons discuté l'année dernière (sauf que nous avons utilisé check au lieu de try ). Je pense qu'il serait crucial que l'on ne puisse pas "revenir" dans le reste du corps de la fonction, une fois que nous sommes à l'étiquette error . Cela garantirait que le goto est quelque peu "structuré" (pas de code spaghetti possible). Une préoccupation qui a été soulevée était que l'étiquette du gestionnaire d'erreurs (l'étiquette error: ) se retrouverait toujours à la fin de la fonction (sinon il faudrait la contourner d'une manière ou d'une autre). Personnellement, j'aime le code de gestion des erreurs à l'écart (à la fin), mais d'autres ont estimé qu'il devrait être visible dès le début.

@mikeshenkel Je vois le retour d'une boucle comme un plus plutôt que comme un négatif. Je suppose que cela encouragerait les développeurs à utiliser une fonction distincte pour gérer le contenu d'une boucle ou à utiliser explicitement err comme nous le faisons actuellement. Ces deux éléments me semblent être de bons résultats.

D'après mon point de vue, je n'ai pas l'impression que cette syntaxe d'essai doive gérer tous les cas d'utilisation, tout comme je ne pense pas avoir besoin d'utiliser le

V, ok := m[touche]

Formulaire de lecture d'une carte

Vous pouvez éviter que les étiquettes goto ne forcent les gestionnaires à la fin de la fonction en ressuscitant la proposition handle / check sous une forme simplifiée. Et si nous utilisions la syntaxe handle err { ... } mais ne laissions pas les gestionnaires s'enchaîner, à la place, seul le dernier est utilisé. Cela simplifie beaucoup cette proposition et est très similaire à l'idée de goto, sauf qu'elle rapproche la manipulation du point d'utilisation.

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
}

En prime, cela a une voie future pour laisser les gestionnaires s'enchaîner, car toutes les utilisations existantes auraient un retour.

@josharian @griesemer si vous introduisez des gestionnaires nommés (dont de nombreuses réponses à vérifier/traiter sont demandées, voir les thèmes récurrents ), il existe des options de syntaxe préférables à try(f(), err) :

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

L'une des choses que j'aime le plus à propos de Go est que sa syntaxe est relativement exempte de ponctuation et peut être lue à haute voix sans problèmes majeurs. Je détesterais vraiment que Go finisse comme un $#@!perl .

Pour moi, faire "essayer" une fonction intégrée et activer les chaînes pose 2 problèmes :

• Il est incohérent avec le reste du flux de contrôle dans go (par exemple, les mots-clés for/if/return/etc).
• Cela rend le code moins lisible.

Je préférerais en faire une déclaration sans parenthèse. Les exemples de la proposition nécessiteraient plusieurs lignes mais deviendraient plus lisibles (c'est-à-dire qu'il serait plus difficile de rater des instances « essayer » individuelles). Oui, cela casserait les analyseurs externes mais je préfère préserver la cohérence.

L'opérateur ternaire est un autre endroit où aller n'a rien et nécessite plus de frappes mais en même temps améliore la lisibilité/maintenabilité. L'ajout de "essayer" dans cette forme plus restreinte permettra de mieux équilibrer l'expressivité et la lisibilité, IMO.

FWIW, panic affecte le flux de contrôle et a des parenthèses, mais go et defer affectent également le flux et non. J'ai tendance à penser que try ressemble plus à defer en ce sens qu'il s'agit d'une opération de flux inhabituelle et qu'il est plus difficile de faire try (try os.Open(file)).Read(buf) parce que nous voulons décourager les one-liners de toute façon, mais peu importe. N'importe quel.

Suggestion que tout le monde détestera pour un nom implicite pour une variable de retour d'erreur finale : $err . C'est mieux que try() IMO. :-)

@griesemer

_"Personnellement, j'aime le code de gestion des erreurs à l'écart (à la fin)"_

+1 à ça !

Je trouve que la gestion des erreurs implémentée _avant_ que l'erreur se produise est beaucoup plus difficile à raisonner que la gestion des erreurs implémentée _après_ que l'erreur se produit. Devoir mentalement revenir en arrière et forcer à suivre le flux logique me donne l'impression d'être de retour en 1980 en écrivant Basic avec GOTOs.

Permettez-moi de proposer encore une autre façon potentielle de gérer les erreurs en utilisant à nouveau CopyFile() comme exemple :

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
}

Les changements de langue requis seraient :

1. Autoriser une construction for error{} , similaire à for range{} mais uniquement saisie en cas d'erreur et exécutée une seule fois.

2. Autoriser l' omission de la capture des valeurs de retour qui implémentent <object>.Error() string mais uniquement lorsqu'une construction for error{} existe dans le même func .

3. Faire sauter le flux de contrôle du programme à la première ligne de la construction for error{} lorsqu'un func renvoie une _"erreur"_ dans sa dernière valeur de retour.

4. Lors du retour d'une _"erreur"_ Go ajouterait une référence à la fonction qui a renvoyé l'erreur qui devrait être récupérable par <error>.Source()

Qu'est-ce qu'une _"erreur"_ ?

Actuellement, une _"erreur"_ est définie comme tout objet qui implémente Error() string et bien sûr n'est pas nil .

Cependant, il est souvent nécessaire d'étendre l'erreur _même en cas de succès_ pour permettre le retour des valeurs nécessaires aux résultats de réussite d'une API RESTful. Je demanderais donc à l'équipe Go de ne pas supposer automatiquement que err!=nil signifie _"erreur"_ mais plutôt de vérifier si un objet d'erreur implémente un IsError() et si IsError() renvoie true avant de supposer que toute valeur autre que nil est une _"erreur"._

_(Je ne parle pas nécessairement du code dans la bibliothèque standard mais principalement si vous choisissez votre flux de contrôle pour créer une branche sur une _"erreur"_. Si vous ne regardez que err!=nil , nous serons très limités dans ce que nous peut faire en termes de valeurs de retour dans nos fonctions.)_

BTW, permettre à tout le monde de tester une _"erreur"_ de la même manière pourrait probablement être fait plus facilement en ajoutant une nouvelle fonction intégrée iserror() :

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()
}

Un côté avantages de permettre la non-capture des _"erreurs"_

Notez qu'autoriser la non-capture de la dernière _"erreur"_ à partir des appels func permettrait une refactorisation ultérieure pour renvoyer des erreurs à partir de func s qui n'avaient initialement pas besoin de renvoyer des erreurs. Et cela permettrait cette refactorisation sans casser le code existant qui utilise cette forme de récupération d'erreur et appelle ces func s.

Pour moi, cette décision de _"Devrais-je renvoyer une erreur ou renoncer à la gestion des erreurs pour appeler la simplicité?"_ est l'un de mes plus grands dilemmes lors de l'écriture de code Go. Autoriser la non-capture des _"erreurs"_ ci-dessus éliminerait pratiquement ce dilemme.

J'ai en fait essayé de mettre en œuvre cette idée en tant que traducteur Go il y a environ six mois. Je n'ai pas d'opinion précise quant à savoir si cette fonctionnalité doit être ajoutée en tant que Go intégré, mais permettez-moi de partager l'expérience (bien que je ne sois pas sûr que ce soit utile).

https://github.com/rhysd/trygo

J'ai appelé le langage étendu TryGo et implémenté le traducteur TryGo to Go.

Avec le traducteur, le 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
}

peut être traduit en

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
}

Pour la restriction de la langue, je ne pouvais pas implémenter l'appel générique try() . Il est restreint à

• RHS de l'énoncé de définition
• RHS de la déclaration d'affectation
• Relevé d'appel

mais je pourrais essayer cela avec mon petit projet. Mon expérience a été

• cela fonctionne très bien et économise plusieurs lignes
• La valeur de retour nommée est en fait inutilisable pour err puisque la valeur de retour de sa fonction est déterminée à la fois par l'affectation et la fonction spéciale try() . Très perturbant
• cette fonction try() manquait de la fonction "erreur d'emballage" comme indiqué ci-dessus.

_"Les deux me semblent être de bons résultats."_

Nous devrons accepter d'être en désaccord ici.

_"cette syntaxe d'essai (n'a pas à) gérer tous les cas d'utilisation"_

Ce mème est probablement le plus troublant. Au moins compte tenu de la résistance de l'équipe / de la communauté Go à tout changement dans le passé qui n'est pas largement applicable.

Si nous acceptons cette justification ici, pourquoi ne pouvons-nous pas revenir sur des propositions antérieures qui ont été rejetées parce qu'elles n'étaient pas largement applicables?

Et sommes-nous maintenant prêts à plaider en faveur de changements dans Go qui ne sont utiles que pour certains cas extrêmes ?

À mon avis, créer ce précédent ne produira pas de bons résultats à long terme...

_"@mikeshenkel"_

PS Je n'ai pas vu votre message au début à cause d'une faute d'orthographe. _(cela ne m'offense pas, c'est juste que je ne reçois pas de notification lorsque mon nom d'utilisateur est mal orthographié...)_

J'apprécie l'engagement envers la rétrocompatibilité qui vous motive à faire try un élément intégré plutôt qu'un mot-clé, mais après avoir lutté avec l'étrangeté totale d'avoir une fonction fréquemment utilisée qui peut changer le flux de contrôle ( panic et recover sont extrêmement rares), je me suis demandé : quelqu'un a-t-il fait une analyse à grande échelle de la fréquence de try comme identifiant dans les bases de code open source ? J'étais curieux et sceptique, alors j'ai fait une recherche préliminaire parmi les éléments suivants :

• 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

Sur les 11 108 770 lignes importantes de Go vivant dans ces dépôts, il n'y avait que 63 instances de try utilisées comme identifiant. Bien sûr, je me rends compte que ces bases de code (bien que vastes, largement utilisées et importantes en elles-mêmes) ne représentent qu'une fraction du code Go disponible, et en plus, que nous n'avons aucun moyen d'analyser directement les bases de code privées, mais c'est certainement un résultat intéressant.

De plus, comme try , comme tout mot-clé, est en minuscules, vous ne le trouverez jamais dans l'API publique d'un package. Les ajouts de mots clés n'affecteront que les éléments internes du package.

Tout cela est une préface à quelques idées que je voulais ajouter au mélange et qui bénéficieraient de try comme mot-clé.

Je proposerais les constructions suivantes.

1) Pas de gestionnaire

// 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) Gestionnaire

Notez que les gestionnaires d'erreurs sont de simples blocs de code, destinés à être intégrés, plutôt que des fonctions. Plus à ce sujet ci-dessous.

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
}

Restrictions proposées :

• Vous ne pouvez que try appeler une fonction. Non try err .
• Si vous ne spécifiez pas de gestionnaire, vous ne pouvez que try depuis une fonction qui renvoie une erreur comme valeur de retour la plus à droite. Il n'y a aucun changement dans le comportement try en fonction de son contexte. Il ne panique jamais (comme discuté beaucoup plus tôt dans le fil).
• Il n'y a aucune "chaîne de gestionnaires" d'aucune sorte. Les gestionnaires ne sont que des blocs de code inlineables.

Avantages:

• La syntaxe try / else pourrait être simplifiée de manière triviale dans le "composé si":
  go a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "error in doSomething:") }
  devient
  go if a, b, err := SomeFunc(); err != nil { return 0, errors.Wrap(err, "error in doSomething:") }
  À mes yeux, les si composés ont toujours semblé plus déroutants qu'utiles pour une raison très simple : les conditions surviennent généralement _après_ une opération et ont quelque chose à voir avec le traitement de ses résultats. Si l'opération est coincée à l'intérieur de l'instruction conditionnelle, il est tout simplement moins évident qu'elle se produise. L'œil est distrait. De plus, la portée des variables définies n'est pas aussi immédiatement évidente que lorsqu'elles sont les plus à gauche sur une ligne.
• Les gestionnaires d'erreurs ne sont intentionnellement pas définis comme des fonctions (ni avec quoi que ce soit qui ressemble à une sémantique de type fonction). Cela nous fait plusieurs choses :
  
  
  
  • Le compilateur peut simplement intégrer un gestionnaire nommé partout où il est référencé. Cela ressemble beaucoup plus à un simple modèle de macro/codegen qu'à un appel de fonction. Le runtime n'a même pas besoin de savoir que les gestionnaires existent.
  
  
  • Nous ne sommes pas limités quant à ce que nous pouvons faire à l'intérieur d'un gestionnaire. Nous contournons la critique de check / handle selon laquelle "ce cadre de gestion des erreurs n'est bon que pour les renflouements". Nous contournons également la critique de la "chaîne de traitement". Tout code arbitraire peut être placé dans l'un de ces gestionnaires, et aucun autre flux de contrôle n'est impliqué.
  
  
  • Nous n'avons pas besoin de détourner return à l'intérieur du gestionnaire pour signifier super return . Le détournement d'un mot-clé est extrêmement déroutant. return signifie simplement return , et il n'y a pas vraiment besoin de super return .
  
  
  • defer n'a pas besoin de clair de lune comme mécanisme de gestion des erreurs. On peut continuer à y penser principalement comme un moyen de nettoyer les ressources, etc.
  
  
• Concernant l'ajout de contexte aux erreurs :
  
  
  
  • L'ajout de contexte avec les gestionnaires est extrêmement simple et ressemble beaucoup aux blocs if err != nil existants
  
  
  • Même si la construction "essayer sans gestionnaire" n'encourage pas directement l'ajout de contexte, il est très simple de refactoriser dans la forme du gestionnaire. Son utilisation prévue serait principalement pendant le développement, et il serait extrêmement simple d'écrire une vérification go vet pour mettre en évidence les erreurs non gérées.
  
  

Toutes mes excuses si ces idées sont très similaires à d'autres propositions - j'ai essayé de toutes les suivre, mais j'ai peut-être raté beaucoup.

@brynbellomy Merci pour l'analyse des mots clés - c'est une information très utile. Il semble que try comme mot-clé puisse convenir. (Vous dites que les API ne sont pas affectées - c'est vrai, mais try peut toujours apparaître comme nom de paramètre ou similaire - donc la documentation peut devoir changer. Mais je suis d'accord que cela n'affecterait pas les clients de ces packages.)

Concernant votre proposition : elle irait très bien même sans gestionnaires nommés, n'est-ce pas ? (Cela simplifierait la proposition sans perte de puissance. On pourrait simplement appeler une fonction locale à partir du gestionnaire en ligne.)

Concernant votre proposition : elle irait très bien même sans gestionnaires nommés, n'est-ce pas ? (Cela simplifierait la proposition sans perte de puissance. On pourrait simplement appeler une fonction locale à partir du gestionnaire en ligne.)

@griesemer En effet - je me sentais plutôt tiède à l'idée de les inclure. Certainement plus Go-ish sans.

D'un autre côté, il semble que les gens veuillent pouvoir gérer les erreurs d'une seule ligne, y compris les lignes simples qui return . Un cas typique serait log, puis return . Si nous déboursons pour une fonction locale dans la clause else , nous perdons probablement cela :

a, b := try SomeFunc() else err {
    someLocalFunc(err)
    return 0, err
}

(Je préfère toujours cela aux ifs composés, cependant)

Cependant, vous pouvez toujours obtenir des retours d'une ligne qui ajoutent un contexte d'erreur en implémentant un simple ajustement gofmt discuté plus tôt dans le fil :

a, b := try SomeFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

Le nouveau mot clé est-il nécessaire dans la proposition ci-dessus ? Pourquoi pas:

SomeFunc() else return
a, b := SomeOtherFunc() else err { return 0, errors.Wrap(err, "bad stuff!") }

@griesemer si les gestionnaires sont de retour sur la table, je vous suggère de créer un nouveau problème pour discuter de try/handle ou try/_label_. Cette proposition a spécifiquement omis les gestionnaires, et il existe d'innombrables façons de les définir et de les invoquer.

Toute personne suggérant des gestionnaires devrait d'abord lire le wiki de vérification/gestion des commentaires. Il y a de fortes chances que tout ce dont vous rêvez y soit déjà décrit :-)
https://github.com/golang/go/wiki/Go2ErrorHandlingFeedback

@smonkewitz non, un nouveau mot-clé n'est pas nécessaire dans cette version car il est lié aux instructions d'affectation, qui a été mentionné plusieurs fois jusqu'à présent dans divers sucres de syntaxe.

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 cette saveur particulière de gestion des erreurs a-t-elle déjà été envisagée par l'équipe go ? Ce n'est pas aussi facile à mettre en œuvre que l'essai intégré proposé, mais cela semble plus idiomatique. ~déclaration inutile, désolé.~

Je voudrais répéter quelque chose que @deanveloper et quelques autres ont dit, mais avec ma propre emphase. Dans https://github.com/golang/go/issues/32437#issuecomment -498939499 @deanveloper a dit :

try est un retour conditionnel. Le flux de contrôle ET les retours sont tous deux maintenus sur des socles en Go. Tout le flux de contrôle dans une fonction est en retrait et tous les retours commencent par return . Mélanger ces deux concepts ensemble dans un appel de fonction facile à manquer semble juste un peu décalé.

De plus, dans cette proposition, try est une fonction qui renvoie des valeurs, elle peut donc être utilisée dans le cadre d'une expression plus grande.

Certains ont fait valoir que panic a déjà créé un précédent pour une fonction intégrée qui modifie le flux de contrôle, mais je pense que panic est fondamentalement différent pour deux raisons :

1. La panique n'est pas conditionnelle ; il abandonne toujours la fonction appelante.
2. Panic ne renvoie aucune valeur et ne peut donc apparaître que comme une instruction autonome, ce qui augmente sa visibilité.

Essayez d'autre part :

1. Est conditionnel ; il peut ou non revenir de la fonction appelante.
2. Renvoie des valeurs et peut apparaître dans une expression composée, éventuellement plusieurs fois, sur une seule ligne, potentiellement au-delà de la marge droite de la fenêtre de mon éditeur.

Pour ces raisons, je pense que try semble plus qu'un "peu décalé", je pense que cela nuit fondamentalement à la lisibilité du code.

Aujourd'hui, lorsque nous rencontrons du code Go pour la première fois, nous pouvons rapidement le parcourir pour trouver les points de sortie possibles et contrôler les points de flux. Je crois que c'est une propriété très précieuse du code Go. En utilisant try , il devient trop facile d'écrire du code dépourvu de cette propriété.

J'admets qu'il est probable que les développeurs Go qui apprécient la lisibilité du code convergent vers des idiomes d'utilisation pour try qui évitent ces pièges de lisibilité. J'espère que cela se produira puisque la lisibilité du code semble être une valeur fondamentale pour de nombreux développeurs Go. Mais il n'est pas évident pour moi que try ajoute suffisamment de valeur par rapport aux idiomes de code existants pour supporter le poids de l'ajout d'un nouveau concept au langage que tout le monde peut apprendre et qui peut si facilement nuire à la lisibilité.

````
si c'est != "cassé" {
ne le répare pas
}

@ChrisHines À votre point (qui est repris ailleurs dans ce fil), ajoutons une autre restriction :

• toute instruction try (même celles sans gestionnaire) doit apparaître sur sa propre ligne.

Vous bénéficieriez toujours d'une grande réduction du bruit visuel. Ensuite, vous avez des retours garantis annotés par return et des retours conditionnels annotés par try , et ces mots-clés se trouvent toujours au début d'une ligne (ou au pire, directement après une affectation de variable).

Donc, rien de ce genre de bêtises:

try EmitEvent(try (try DecodeMsg(m)).SaveToDB())

mais plutôt ceci :

dm := try DecodeMsg(m)
um := try dm.SaveToDB()
try EmitEvent(um)

qui se sent encore plus clair que cela:

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
}

Une chose que j'aime à propos de cette conception est qu'il est impossible d'ignorer silencieusement les erreurs sans toujours annoter qu'une erreur pourrait se produire . Alors qu'en ce moment, vous voyez parfois x, _ := SomeFunc() (quelle est la valeur de retour ignorée ? une erreur ? quelque chose d'autre ?), maintenant vous devez annoter clairement :

x := try SomeFunc() else err {}

Depuis mon précédent message à l'appui de la proposition, j'ai vu deux idées publiées par @jagv (sans paramètre try renvoie *error ) et par @josharian (gestionnaires d'erreurs étiquetés) que je crois en un une forme légèrement modifiée améliorerait considérablement la proposition.

En rassemblant ces idées avec une autre que j'ai moi-même eue, nous aurions quatre versions de try :

1. essayer()
2. essayez (paramètres)
3. essayer (paramètres, étiquette)
4. essayez (paramètres, panique)

1 renverrait simplement un pointeur vers le paramètre de retour d'erreur (ERP) ou nil s'il n'y en avait pas (#4 uniquement). Cela fournirait une alternative à un ERP nommé sans qu'il soit nécessaire d'ajouter un autre intégré.

2 fonctionnerait exactement comme actuellement envisagé. Une erreur non nulle serait renvoyée immédiatement mais pourrait être décorée par une instruction defer .

3 fonctionnerait comme suggéré par @josharian , c'est-à-dire que sur une erreur non nulle, le code se brancherait sur l'étiquette. Cependant, il n'y aurait pas d'étiquette de gestionnaire d'erreurs par défaut car ce cas dégénérerait maintenant en #2.

Il me semble que ce sera généralement une meilleure façon de décorer les erreurs (ou de les gérer localement puis de retourner nil) que defer car c'est plus simple et plus rapide. Quiconque n'aimait pas cela pouvait toujours utiliser #2.

Il serait préférable de placer l'étiquette/le code de gestion des erreurs vers la fin de la fonction et de ne pas revenir dans le reste du corps de la fonction. Cependant, je ne pense pas que le compilateur devrait appliquer non plus car il pourrait y avoir des occasions étranges où ils sont utiles et l'application pourrait être difficile dans tous les cas.

Donc, l'étiquette normale et le comportement goto s'appliqueraient sous réserve (comme l'a dit @josharian ) que # 26058 soit corrigé en premier, mais je pense qu'il devrait être corrigé de toute façon.

Le nom de l'étiquette ne peut pas être panic car cela entrerait en conflit avec #4.

4 serait panic immédiatement plutôt que de retourner ou de se ramifier. Par conséquent, s'il s'agissait de la seule version de try utilisée dans une fonction particulière, aucun ERP ne serait nécessaire.

J'ai ajouté ceci afin que le package de test puisse fonctionner comme il le fait maintenant sans avoir besoin d'autres modifications intégrées ou autres. Cependant, cela pourrait également être utile dans d'autres scénarios _fatal_.

Cela doit être une version distincte de try au lieu de se brancher sur un gestionnaire d'erreurs, puis de paniquer à partir de ce qui nécessiterait toujours un ERP.

L'un des types de réactions les plus fortes à la proposition initiale était l'inquiétude concernant la perte de visibilité facile du flux normal de l'endroit où une fonction revient.

Par exemple, @deanveloper a très bien exprimé cette préoccupation dans https://github.com/golang/go/issues/32437#issuecomment -498932961, qui, je pense, est le commentaire le plus voté ici.

@dominikh a écrit dans https://github.com/golang/go/issues/32437#issuecomment -499067357 :

Dans le code gofmt'ed, un retour correspond toujours à /^\t*return / - c'est un modèle très trivial à repérer à l'œil nu, sans aucune aide. try, d'autre part, peut se produire n'importe où dans le code, imbriqué arbitrairement profondément dans les appels de fonction. Aucune formation ne nous permettra de repérer immédiatement tous les flux de contrôle dans une fonction sans l'aide d'outils.

Pour vous aider, @brynbellomy a suggéré hier :

toute instruction try (même celles sans gestionnaire) doit apparaître sur sa propre ligne.

En allant plus loin, le try pourrait être requis pour être le début de la ligne, même pour une affectation.

Donc ça pourrait être :

try dm := DecodeMsg(m)
try um := dm.SaveToDB()
try EmitEvent(um)

plutôt que ce qui suit (de l'exemple de @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
}

Cela semble préserver une bonne quantité de visibilité, même sans aucune assistance d'éditeur ou d'IDE, tout en réduisant le passe-partout.

Cela pourrait fonctionner avec l'approche basée sur le report actuellement proposée qui repose sur des paramètres de résultat nommés, ou cela pourrait fonctionner avec la spécification de fonctions de gestionnaire normales. (Spécifier des fonctions de gestionnaire sans exiger de valeurs de retour nommées me semble mieux que d'exiger des valeurs de retour nommées, mais c'est un point distinct).

La proposition comprend cet exemple :

info := try(try(os.Open(file)).Stat())    // proposed try built-in

Cela pourrait plutôt être :

try f := os.Open(file)
try info := f.Stat()

C'est encore une réduction du passe-partout par rapport à ce que quelqu'un pourrait écrire aujourd'hui, même s'il n'est pas aussi court que la syntaxe proposée. Ce serait peut-être suffisamment court ?

@elagergren-spideroak a fourni cet exemple :

try(try(try(to()).parse().this)).easily())

Je pense que cela a des parenthèses incompatibles, ce qui est peut-être un point délibéré ou un peu d'humour subtil, donc je ne sais pas si cet exemple a l'intention d'avoir 2 try ou 3 try . Dans tous les cas, il serait peut-être préférable d'exiger une répartition sur 2-3 lignes commençant par try .

@thepudds , c'est ce que je voulais dire dans mon commentaire précédent. Sauf que donné

try f := os.Open(file)
try info := f.Stat()

Une chose évidente à faire est de considérer try comme un bloc try où plusieurs phrases peuvent être mises entre parenthèses . Ainsi, ce qui précède peut devenir

try (
    f := os.Open(file)
    into := f.Stat()
)

Si le compilateur sait comment gérer cela, la même chose fonctionne également pour l'imbrication. Alors maintenant, ce qui précède peut devenir

try info := os.Open(file).Stat()

À partir des signatures de fonction, le compilateur sait que Open peut renvoyer une valeur d'erreur et, comme il se trouve dans un bloc try, il doit générer une gestion des erreurs, puis appeler Stat() sur la valeur renvoyée primaire, etc.

La prochaine chose est d'autoriser les déclarations où aucune valeur d'erreur n'est générée ou est gérée localement. Donc, vous pouvez maintenant dire

try (
    f := os.Open(file)
    debug("f: %v\n", f) // debug returns nothing
    into := f.Stat()
)

Cela permet de faire évoluer le code sans avoir à réorganiser les blocs try. Mais pour une raison étrange, les gens semblent penser que la gestion des erreurs doit être explicitement expliquée ! Ils veulent

try(try(try(to()).parse()).this)).easily())

Alors que je suis parfaitement bien avec

try to().parse().this().easily()

Même si dans les deux cas, exactement le même code de vérification d'erreur peut être généré. Mon point de vue est que vous pouvez toujours écrire un code spécial pour la gestion des erreurs si vous en avez besoin. try (ou quel que soit le nom que vous préférez lui donner) désencombre simplement la gestion des erreurs par défaut (qui consiste à la transmettre à l'appelant).

Un autre avantage est que si le compilateur génère la gestion des erreurs par défaut, il peut ajouter des informations d'identification supplémentaires afin que vous sachiez laquelle des quatre fonctions ci-dessus a échoué.

J'étais quelque peu préoccupé par la lisibilité des programmes où try apparaît à l'intérieur d'autres expressions. J'ai donc exécuté grep "return .*err$" sur la bibliothèque standard et j'ai commencé à lire des blocs au hasard. Il y a 7214 résultats, je n'en ai lu que quelques centaines.

La première chose à noter est que là où try s'applique, cela rend presque tous ces blocs un peu plus lisibles.

La deuxième chose est que très peu d'entre eux, moins de 1 sur 10, mettraient try dans une autre expression. Le cas typique est celui des déclarations de la forme x := try(...) ou ^try(...)$ .

Voici quelques exemples où try apparaîtrait dans une autre expression :

texte/modèle

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
}

devient:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        return !try(le(arg1, arg2)), nil
}

texte/modèle

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())
                }
        ...
        }
}

devient

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())
                }
        ...
        }
}

(c'est l'exemple le plus discutable que j'ai vu)

regexp/syntaxe :

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)
        ...
}

devient

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        c, t = try(nextRune(t))
        p.literal(c)
        ...
}

Ce n'est pas un exemple d'essayer dans une autre expression mais je veux l'appeler car cela améliore la lisibilité. Il est beaucoup plus facile de voir ici que les valeurs de c et t vivent au-delà de la portée de l'instruction if.

réseau/http

net/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

devient:

        req.Header = Header(try(tp.ReadMIMEHeader())

base de données/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

devient

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

base de données/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

devient

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }

réseau/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
        }

devient

        if http2isconnectioncloserequest(req) && dialonmiss {
                // it gets its own connection.
                http2tracegetconn(req, addr)
                const singleuse = true
                return try(p.t.dialclientconn(addr, singleuse))
        }

réseau/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
}

devient

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

(Celui-ci, j'aime beaucoup.)

réseau/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

devient

        hc = try(fr.ReadFrame()).(*http2ContinuationFrame)// guaranteed by checkFrameOrder

}

(Aussi sympa.)

net :

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

devient

        if ctrlFn != nil {
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), try(newRawConn(fd))))
        }

c'est peut-être trop, et à la place ça devrait être:

        if ctrlFn != nil {
                c := try(newRawConn(fd))
                try(ctrlFn(fd.ctrlNetwork(), laddr.String(), c))
        }

Dans l'ensemble, j'apprécie assez l'effet de try sur le code de bibliothèque standard que j'ai lu.

Un dernier point : voir try appliqué pour lire du code au-delà des quelques exemples de la proposition était instructif. Je pense qu'il vaut la peine d'envisager d'écrire un outil pour convertir automatiquement le code pour utiliser try (où cela ne change pas la sémantique du programme). Il serait intéressant de lire un échantillon des différences produites par rapport aux packages populaires sur github pour voir si ce que j'ai trouvé dans la bibliothèque standard tient la route. Les résultats d'un tel programme pourraient fournir un aperçu supplémentaire de l'effet de la proposition.

@crawshaw merci d'avoir fait ça, c'était super de le voir en action. Mais le voir en action m'a fait prendre plus au sérieux les arguments contre la gestion des erreurs en ligne que j'avais jusqu'à présent rejetés.

Comme c'était si proche de la suggestion intéressante de @thepudds de faire try une déclaration, j'ai réécrit tous les exemples en utilisant cette syntaxe et je l'ai trouvé beaucoup plus clair que l'expression- try ou le statu quo, sans nécessiter trop de lignes supplémentaires :

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
        }

Celui-ci serait sans doute meilleur avec une expression- try s'il y avait plusieurs champs qui devaient être try -ed, mais je préfère toujours l'équilibre de ce compromis

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

C'est fondamentalement le pire des cas pour cela et ça a l'air bien:

        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
        }

J'ai débattu avec moi-même si if try serait ou devrait être légal, mais je n'ai pas pu trouver d'explication raisonnable pour laquelle cela ne devrait pas l'être et cela fonctionne assez bien ici:

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)
        }

Parcourir les exemples de @crawshaw ne fait que me rendre plus sûr que le flux de contrôle sera souvent suffisamment crypté pour être encore plus prudent sur la conception. Relatant même une petite quantité de complexité devient difficile à lire et facile à bâcler. Je suis heureux de voir les options envisagées, mais compliquer le flux de contrôle dans un langage aussi réservé semble exceptionnellement hors de propos.

func (f *http2Framer) endWrite() error {
        ...
        if try(f.w.Write(f.wbuf) != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

De plus, try n'est pas "essayer" quoi que ce soit. C'est un "relais de protection". Si la sémantique de base de la proposition est désactivée, je ne suis pas surpris que le code résultant soit également problématique.

func (f *http2Framer) endWrite() error {
        ...
        relay n := f.w.Write(f.wbuf)
        return checkShortWrite(n, len(f.wbuf))
}

Si vous faites une instruction try, vous pouvez utiliser un indicateur pour indiquer quelle valeur de retour et quelle action :

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

Vous avez toujours besoin d'une syntaxe de sous-expression (Russ a déclaré que c'est une exigence), au moins pour les actions de panique et d'ignorance.

Tout d'abord, j'applaudis @crawshaw d'avoir pris le temps d'examiner environ 200 exemples réels et d'avoir pris le temps de son article réfléchi ci-dessus.

Deuxièmement, @jimmyfrasche , concernant votre réponse ici à propos de l'exemple http2Framer :

J'ai débattu avec moi-même si if try serait ou devrait être légal, mais je n'ai pas pu trouver d'explication raisonnable pour laquelle cela ne devrait pas l'être et cela fonctionne assez bien ici :

```
func (f *http2Framer) erreur endWrite() {
...
if try n := fwWrite(f.wbuf); n != len(f.wbuf) {
retourner io.ErrShortWrite
}
retour nul
}

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) erreur endWrite() {
...
essayez n := fwEcrit(f.wbuf)
si n != len(f.wbuf) {
retourner io.ErrShortWrite
}
retour nul
}
`` 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 essayer`.

@deanveloper a écrit ci-dessus dans https://github.com/golang/go/issues/32437#issuecomment -498932961 :

Revenir d'une fonction a semblé avoir été une chose "sacrée" à faire

Cet exemple spécifique http2Framer finit par ne pas être aussi court qu'il pourrait l'être. Cependant, il retient le retour d'une fonction plus "sacrée" si le try doit être la première chose sur une ligne.

@crawshaw a mentionné :

La deuxième chose est que très peu d'entre eux, moins de 1 sur 10, mettraient try dans une autre expression. Le cas typique est celui des instructions de la forme x := try(...) ou ^try(...)$.

Peut-être est-il acceptable de n'aider que partiellement ces 1 exemples sur 10 avec une forme plus restreinte de try , surtout si le cas typique de ces exemples se termine avec le même nombre de lignes même si try est nécessaire d'être la première chose sur une ligne?

@jimmyfrasche

@crawshaw merci d'avoir fait ça, c'était super de le voir en action. Mais le voir en action m'a fait prendre plus au sérieux les arguments contre la gestion des erreurs en ligne que j'avais jusqu'à présent rejetés.

Comme c'était si proche de la suggestion intéressante de @thepudds de faire try une déclaration, j'ai réécrit tous les exemples en utilisant cette syntaxe et je l'ai trouvé beaucoup plus clair que l'expression- try ou le statu quo, sans nécessiter trop de lignes supplémentaires :

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

Votre premier exemple illustre bien pourquoi je préfère fortement l'expression- try . Dans votre version, je dois mettre le résultat de l'appel à le dans une variable, mais cette variable n'a pas de signification sémantique que le terme le n'implique pas déjà. Donc, je ne peux pas lui donner de nom qui ne soit ni dénué de sens (comme x ) ni redondant (comme lessOrEqual ). Avec expression- try , aucune variable intermédiaire n'est nécessaire, donc ce problème ne se pose même pas.

Je préférerais ne pas avoir à faire d'efforts mentaux pour inventer des noms pour des choses qu'il vaut mieux laisser anonymes.

Je suis heureux d'apporter mon soutien derrière les derniers messages où try (le mot-clé) a été déplacé au début de la ligne. Il devrait vraiment partager le même espace visuel que return .

Re : la suggestion de @jimmyfrasche d'autoriser try dans les instructions composées if , c'est exactement le genre de chose que je pense que beaucoup ici essaient d'éviter, pour plusieurs raisons :

• il regroupe deux mécanismes de flux de contrôle très différents en une seule ligne
• l'expression try est en fait évaluée en premier et peut provoquer le retour de la fonction, mais elle apparaît après le if
• ils reviennent avec des erreurs totalement différentes, dont une que nous ne voyons pas réellement dans le code, et une que nous faisons
• cela rend moins évident que le try n'est en fait pas géré, car le bloc ressemble beaucoup à un bloc de gestionnaire (même s'il gère un problème totalement différent)

On pourrait aborder cette situation sous un angle légèrement différent qui favorise le fait de pousser les gens à manipuler les try s. Que diriez-vous de permettre à la syntaxe try / else de contenir des conditions suivantes (ce qui est un modèle courant avec de nombreuses fonctions d'E/S qui renvoient à la fois un err et un n , l'un ou l'autre pouvant indiquer un problème) :

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
}

Dans le cas où vous ne gérez pas l'erreur renvoyée par .Write , vous auriez toujours une annotation claire indiquant que .Write pourrait être une erreur (comme l'a souligné @thepudds):

func (f *http2Framer) endWrite() error {
        // ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

Je seconde la réponse de @daved . À mon avis, chaque exemple mis en évidence par @crawshaw est devenu moins clair et plus sujet aux erreurs à la suite de try .

Je suis heureux d'apporter mon soutien derrière les derniers messages où try (le mot-clé) a été déplacé au début de la ligne. Il devrait vraiment partager le même espace visuel que return .

Compte tenu des deux options pour ce point et en supposant qu'une a été choisie et crée ainsi un précédent pour les futures fonctionnalités potentielles :

UNE.)

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")
}

Lequel des deux offre plus de flexibilité pour l'utilisation future de nouveaux mots clés ? _(Je ne connais pas la réponse à cette question car je ne maîtrise pas l'art sombre d'écrire des compilateurs.)_ Une approche serait-elle plus limitative qu'une autre ?

@davecheney @daved @crawshaw
J'aurais tendance à être d'accord avec les Daves sur celui-ci : dans les exemples de @crawshaw , il y a beaucoup d'instructions try intégrées profondément dans les lignes qui contiennent beaucoup d'autres choses. Vraiment difficile de repérer les points de sortie. De plus, les try semblent encombrer assez mal les choses dans certains des exemples.

Voir un tas de code stdlib transformé comme celui-ci est très utile, j'ai donc pris les mêmes exemples mais les ai réécrits selon la proposition alternative, qui est plus restrictive :

• try comme mot-clé
• un seul try par ligne
• try doit être au début d'une ligne

J'espère que cela nous aidera à comparer. Personnellement, je trouve que ces exemples semblent beaucoup plus concis que leurs originaux, mais sans obscurcir le flux de contrôle. try reste très visible partout où il est utilisé.

texte/modèle

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
}

devient:

func gt(arg1, arg2 reflect.Value) (bool, error) {
        // > is the inverse of <=.
        try lessOrEqual := le(arg1, arg2)
        return !lessOrEqual, nil
}

texte/modèle

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())
                }
        ...
        }
}

devient

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())
                }
        ...
        }
}

regexp/syntaxe :

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)
        ...
}

devient

func Parse(s string, flags Flags) (*Regexp, error) {
        ...
        try c, t = nextRune(t)
        p.literal(c)
        ...
}

réseau/http

net/http/request.go:readRequest

        mimeHeader, err := tp.ReadMIMEHeader()
        if err != nil {
                return nil, err
        }
        req.Header = Header(mimeHeader)

devient:

        try mimeHeader := tp.ReadMIMEHeader()
        req.Header = Header(mimeHeader)

base de données/sql

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                connector, err := driverCtx.OpenConnector(dataSourceName)
                if err != nil {
                        return nil, err
                }
                return OpenDB(connector), nil
        }

devient

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                try connector := driverCtx.OpenConnector(dataSourceName)
                return OpenDB(connector), nil
        }

base de données/sql

        si, err := ctxDriverPrepare(ctx, dc.ci, query)
        if err != nil {
                return nil, err
        }
        ds := &driverStmt{Locker: dc, si: si}

devient

        try si := ctxDriverPrepare(ctx, dc.ci, query)
        ds := &driverStmt{Locker: dc, si: si}

réseau/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
        }

devient

        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
        }

réseau/http
Celui-ci ne nous fait pas économiser de lignes, mais je le trouve beaucoup plus clair car if err == nil est une construction relativement rare.

func (f *http2Framer) endWrite() error {
        ...
        n, err := f.w.Write(f.wbuf)
        if err == nil && n != len(f.wbuf) {
                err = io.ErrShortWrite
        }
        return err
}

devient

func (f *http2Framer) endWrite() error {
        ...
        try n := f.w.Write(f.wbuf)
        if n != len(f.wbuf) {
                return io.ErrShortWrite
        }
        return nil
}

réseau/http

        if f, err := fr.ReadFrame(); err != nil {
                return nil, err
        } else {
                hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
        }

devient

        try f := fr.ReadFrame()
        hc = f.(*http2ContinuationFrame) // guaranteed by checkFrameOrder
}

rapporter:

        if ctrlFn != nil {
                c, err := newRawConn(fd)
                if err != nil {
                        return err
                }
                if err := ctrlFn(fd.ctrlNetwork(), laddr.String(), c); err != nil {
                        return err
                }
        }

devient

        if ctrlFn != nil {
                try c := newRawConn(fd)
                try ctrlFn(fd.ctrlNetwork(), laddr.String(), c)
        }

@james-lawrence En réponse à https://github.com/golang/go/issues/32437#issuecomment -500116099 : Je ne me souviens pas que des idées comme un , err facultatif aient été sérieusement envisagées, non. Personnellement, je pense que c'est une mauvaise idée, car cela signifie que si une fonction change pour ajouter un paramètre de fin error , le code existant continuera à compiler, mais agira très différemment.

L'utilisation de defer pour gérer les erreurs a beaucoup de sens, mais cela conduit à devoir nommer l'erreur et un nouveau type de passe- if err != nil .

Les gestionnaires externes doivent faire ceci :

func handler(err *error) {
  if *err != nil {
    *err = handle(*err)
  }
} 

qui s'habitue comme

defer handler(&err)

Les gestionnaires externes n'ont besoin d'être écrits qu'une seule fois, mais il faudrait deux versions de nombreuses fonctions de gestion des erreurs : celle destinée à être différée et celle à utiliser de manière régulière.

Les gestionnaires internes doivent faire ceci :

defer func() {
  if err != nil {
    err = handle(err)
  }
}()

Dans les deux cas, l'erreur de la fonction externe doit être nommée pour être accessible.

Comme je l'ai mentionné plus tôt dans le fil, cela peut être résumé en une seule fonction :

func catch(err *error, handle func(error) error) {
  if *err != nil && handle != nil {
    *err = handle(*err)
  }
}

Cela va à l'encontre de l'inquiétude de @griesemer concernant l'ambiguïté des fonctions de gestionnaire de nil et a son propre passe-partout defer et func(err error) error , en plus de devoir nommer err dans la fonction externe.

Si try finit comme mot-clé, alors il pourrait être judicieux d'avoir un mot-clé catch , qui sera également décrit ci-dessous.

Syntaxiquement, ce serait un peu comme handle :

catch err {
  return handleThe(err)
}

Sémantiquement, ce serait du sucre pour le code du gestionnaire interne ci-dessus :

defer func() {
  if err != nil {
    err = handleThe(err)
  }
}()

Comme c'est quelque peu magique, il pourrait saisir l'erreur de la fonction externe, même si elle n'était pas nommée. (Le err après catch ressemble plus à un nom de paramètre pour le bloc catch ).

catch aurait la même restriction que try qu'il doit être dans une fonction qui a un retour d'erreur final, car ils sont tous les deux du sucre qui en dépend.

C'est loin d'être aussi puissant que la proposition originale handle , mais cela éviterait l'obligation de nommer une erreur afin de la gérer et cela supprimerait le nouveau passe-partout décrit ci-dessus pour les gestionnaires internes tout en le rendant assez facile à ne pas nécessitent des versions distinctes des fonctions pour les gestionnaires externes.

La gestion des erreurs compliquées peut nécessiter de ne pas utiliser catch la même manière qu'elle peut nécessiter de ne pas utiliser try .

Comme ce sont tous les deux du sucre, il n'est pas nécessaire d'utiliser catch avec try . Les gestionnaires catch sont exécutés chaque fois que la fonction renvoie une erreur autre que nil , permettant, par exemple, de conserver une journalisation rapide :

catch err {
  log.Print(err)
  return err
}

ou simplement envelopper toutes les erreurs renvoyées :

catch err {
  return fmt.Errorf("foo: %w", err)
}

@ianlancetaylor

_" Je pense que c'est une mauvaise idée, car cela signifie que si une fonction change pour ajouter un paramètre de fin error , le code existant continuera à compiler, mais agira très différemment."_

C'est probablement la bonne façon de voir les choses, si vous êtes en mesure de contrôler à la fois le code en amont et en aval, de sorte que si vous devez modifier une signature de fonction afin de renvoyer également une erreur, vous pouvez le faire.

Mais je vous demanderais de considérer ce qui se passe lorsque quelqu'un ne contrôle ni en amont ni en aval de ses propres packages ? Et aussi pour considérer les cas d'utilisation où des erreurs peuvent être ajoutées, et que se passe-t-il si des erreurs doivent être ajoutées mais que vous ne pouvez pas forcer le code en aval à changer ?

Pouvez-vous penser à un exemple où quelqu'un changerait de signature pour ajouter une valeur de retour ? Pour moi, ils sont généralement tombés dans la catégorie _"Je ne savais pas qu'une erreur se produirait"_ ou _"Je me sens paresseux et je ne veux pas faire d'effort car l'erreur ne se produira probablement pas." _

Dans ces deux cas, je pourrais ajouter un retour d'erreur car il devient évident qu'une erreur doit être traitée. Lorsque cela se produit, si je ne peux pas modifier la signature parce que je ne veux pas rompre la compatibilité pour les autres développeurs utilisant mes packages, que faire ? Je suppose que la grande majorité du temps, l'erreur se produira et que le code qui a appelé la fonction qui ne renvoie pas l'erreur agira très différemment, _de toute façon._

En fait, je fais rarement ce dernier mais trop souvent le premier. Mais j'ai remarqué que les packages tiers ignorent fréquemment les erreurs de capture là où elles devraient se trouver, et je le sais parce que lorsque j'affiche leur code dans les drapeaux GoLand en orange vif à chaque fois. J'aimerais pouvoir soumettre des demandes d'extraction pour ajouter la gestion des erreurs aux packages que j'utilise beaucoup, mais si je le fais, la plupart ne les accepteront pas car je briserais leurs signatures de code.

En n'offrant pas de moyen rétrocompatible d'ajouter des erreurs à renvoyer par les fonctions, les développeurs qui distribuent du code et se soucient de ne pas casser les choses pour leurs utilisateurs ne pourront pas faire évoluer leurs packages pour inclure la gestion des erreurs comme ils le devraient.

Peut-être plutôt que de considérer le problème étant que le code agira différemment, considérez plutôt le problème comme un défi d'ingénierie concernant la façon de minimiser les inconvénients d'une méthode qui ne capture pas activement une erreur ? Cela aurait une valeur plus large et à plus long terme.

Par exemple, envisagez d'ajouter un gestionnaire d'erreurs de package que l'on doit définir avant de pouvoir ignorer les erreurs ?

Pour être franc, l'idiome de Go consistant à renvoyer des erreurs en plus des valeurs de retour régulières était l'une de ses meilleures innovations. Mais comme cela arrive souvent lorsque vous améliorez les choses, vous exposez souvent d'autres faiblesses et je soutiendrai que la gestion des erreurs de Go n'a pas suffisamment innové.

Nous, Gophers, sommes devenus habitués à renvoyer une erreur plutôt qu'à lancer une exception, donc la question que je me pose est _ "Pourquoi ne devrions-nous pas renvoyer des erreurs de chaque fonction?" _ Nous ne le faisons pas toujours car écrire du code sans gestion des erreurs est plus pratique que de coder avec. Nous omettons donc la gestion des erreurs lorsque nous pensons pouvoir nous en éloigner. Mais souvent nous devinons mal.

Donc vraiment, s'il était possible de comprendre comment rendre le code élégant et lisible, je dirais que les valeurs de retour et les erreurs devraient vraiment être traitées séparément, et que _chaque_ fonction devrait avoir la capacité de renvoyer des erreurs indépendamment de ses signatures de fonction passées. Et faire en sorte que le code existant gère avec élégance le code qui génère maintenant des erreurs serait une entreprise louable.

Je n'ai rien proposé parce que je n'ai pas pu imaginer une syntaxe viable, mais si nous voulons être honnêtes avec nous-mêmes, tout ce qui se passe dans ce fil et lié à la gestion des erreurs de Go en général n'a-t-il pas été lié au fait que la gestion des erreurs et la logique du programme sont des compagnons de lit étranges, donc idéalement, les erreurs seraient mieux gérées hors bande d'une manière ou d'une autre?

try en tant que mot-clé aide certainement à la lisibilité (par rapport à un appel de fonction) et semble moins complexe. @brynbellomy @crawshaw merci d'avoir pris le temps d'écrire les exemples.

Je suppose que ma pensée générale est que try en fait trop. Il résout : appeler la fonction, affecter des variables, vérifier l'erreur et renvoyer l'erreur si elle existe. Je propose plutôt de réduire la portée et de résoudre uniquement pour le retour conditionnel : "return if last arg not nil".

Ce n'est probablement pas une idée nouvelle... Mais après avoir parcouru les propositions dans le wiki error feedback , je ne l'ai pas trouvé (cela ne veut pas dire qu'il n'y est pas)

Mini proposition sur retour conditionnel

extrait:

err, thing := newThing(name)
refuse nil, err

Je l'ai également ajouté au wiki sous "idées alternatives"

Ne rien faire semble également être une option très raisonnable.

@alexhornbake ça me donne une idée un peu différente qui serait plus utile

assert(nil, err)
assert(len(a), len(b))
assert(true, condition)
assert(expected, given)

de cette façon, cela ne s'appliquerait pas seulement à la vérification des erreurs, mais à de nombreux types d'erreurs logiques.

Le donné serait enveloppé dans une erreur et renvoyé.

@alexhornbake

Tout comme try n'essaie pas réellement, refuse ne "refuse" pas réellement. L'intention commune ici a été de définir un "relais de protection" ( relay est court, précis et allitératif à return ) qui "se déclenche" lorsque l'une des valeurs câblées répond à une condition (ie est une erreur non nulle). C'est une sorte de disjoncteur et, je crois, peut ajouter de la valeur si sa conception était limitée à des cas inintéressants pour simplement réduire certains des passe-partout les plus bas. Tout ce qui est complexe à distance devrait s'appuyer sur du code Go simple.

Je félicite également Cranshaw pour son travail de recherche dans la bibliothèque standard, mais je suis arrivé à une conclusion très différente... Je pense que cela rend presque tous ces extraits de code plus difficiles à lire et plus sujets aux malentendus.

        req.Header = Header(try(tp.ReadMIMEHeader())

Je vais très souvent rater cette erreur. Une lecture rapide me donne "ok, définissez l'en-tête sur l'en-tête de ReadMimeHeader de la chose".

        if driverCtx, ok := driveri.(driver.DriverContext); ok {
                return OpenDB(try(driverCtx.OpenConnector(dataSourceName))), nil
        }

Celui-ci, mes yeux se croisent en essayant d'analyser cette ligne OpenDB. Il y a tellement de densité là-bas ... Cela montre le problème majeur de tous les appels de fonction imbriqués, en ce sens que vous devez lire de l'intérieur vers l'extérieur et que vous devez l'analyser dans votre tête afin de déterminer où se trouve la partie la plus interne .

Notez également que cela peut revenir de deux endroits différents dans la même ligne.. .vous allez déboguer, et cela va dire qu'il y a eu une erreur renvoyée par cette ligne, et la première chose que tout le monde va faire est d'essayer de comprendre pourquoi OpenDB échoue avec cette erreur étrange, alors qu'il s'agit en fait d'un échec d'OpenConnector (ou vice versa).

        ds := &driverStmt{
                Locker: dc,
                si: try(ctxDriverPrepare(ctx, dc.ci, query)),
        }   

C'est un endroit où le code peut échouer là où auparavant cela aurait été impossible. Sans try , la construction du littéral struct ne peut pas échouer . Mes yeux vont le parcourir comme "ok, construire un driverStmt ... continuer .." et il sera si facile de le manquer qu'en fait, cela peut entraîner une erreur de votre fonction. La seule façon qui aurait été possible auparavant est si ctxDriverPrepare a paniqué... et nous savons tous que c'est un cas qui 1.) ne devrait fondamentalement jamais arriver et 2.) si c'est le cas, cela signifie que quelque chose ne va pas du tout.

Faire essayer un mot clé et une déclaration résout beaucoup de mes problèmes avec cela. Je sais que ce n'est pas rétrocompatible, mais je ne pense pas que l'utilisation d'une version pire soit la solution au problème de rétrocompatibilité.

@daved Je ne suis pas sûr de suivre. N'aimez-vous pas le nom, ou n'aimez-vous pas l'idée ?

Quoi qu'il en soit, j'ai posté ceci ici comme alternative... S'il y a un intérêt légitime, je peux ouvrir un nouveau sujet de discussion, je ne veux pas polluer ce fil (peut-être trop tard ?) nous un sens... Bien sûr ouvert aux noms alternatifs. La partie importante est "le retour conditionnel sans essayer de gérer l'affectation".

Bien que j'aime la proposition de catch de @jimmyfrasche , je voudrais proposer une alternative :
go handler fmt.HandleErrorf("copy %s %s", src, dst)
serait équivalent à :
go defer func(){ if(err != nil){ fmt.HandleErrorf(&err,"copy %s %s", src, dst) } }()
où err est la dernière valeur de retour nommée, avec le type error. Cependant, les gestionnaires peuvent également être utilisés lorsque les valeurs de retour ne sont pas nommées. Le cas plus général serait également autorisé :
go handler func(err *error){ *err = fmt.Errorf("foo: %w", *err) }() `
Le principal problème que j'ai avec l'utilisation de valeurs de retour nommées (que catch ne résout pas) est que err est superflu. Lors du report d'un appel à un gestionnaire comme fmt.HandleErrorf , il n'y a pas de premier argument raisonnable sauf un pointeur vers la valeur de retour d'erreur, pourquoi donner à l'utilisateur la possibilité de faire une erreur ?

Par rapport à catch, la principale différence est que handler facilite un peu l'appel de gestionnaires prédéfinis au détriment de rendre plus verbeux pour les définir en place. Je ne suis pas sûr que ce soit l'idéal, mais je pense que c'est plus conforme à la proposition initiale.

@yiyus catch , comme je l'ai défini, il n'est pas nécessaire que err soit nommé sur la fonction contenant le catch .

Dans catch err { , le err correspond au nom de l'erreur dans le bloc catch . C'est comme un nom de paramètre de fonction.

Avec cela, il n'y a pas besoin de quelque chose comme fmt.HandleErrorf car vous pouvez simplement utiliser le fmt.Errorf normal :

func f() error {
  catch err {
    return fmt.Errorf("foo: %w", err)
  }
  return errors.New("bar")
}

qui renvoie une erreur qui s'imprime sous la forme foo: bar .

Je n'aime pas cette approche, à cause de:

• L'appel de la fonction try() interrompt l'exécution du code dans la fonction parent.
• il n'y a pas de mot-clé return , mais le code renvoie en fait.

De nombreuses façons de faire des gestionnaires sont proposées, mais je pense qu'elles manquent souvent deux exigences clés :

1. Il doit être significativement différent et meilleur que if x, err := thingie(); err != nil { handle(err) } . Je pense que les suggestions du type try x := thingie else err { handle(err) } ne répondent pas à cette barre. Pourquoi ne pas simplement dire if ?

2. Il doit être orthogonal à la fonctionnalité existante de defer . C'est-à-dire qu'il devrait être suffisamment différent pour qu'il soit clair que le mécanisme de gestion proposé est nécessaire en soi sans créer de cas bizarres lorsque handle et defer interagissent.

Veuillez garder ces desiderata à l'esprit lorsque nous discutons de mécanismes alternatifs pour try /handle.

@carlmjohnson J'aime l' idée catch @jimmyfrasche concernant votre point 2 - c'est juste du sucre de syntaxe pour un defer qui économise 2 lignes et vous permet d'éviter d'avoir à nommer la valeur de retour d'erreur (qui dans tourner exigerait également que vous nommiez tous les autres si vous ne l'aviez pas déjà fait). Cela ne pose pas de problème d'orthogonalité avec defer , car c'est defer .

faisant écho à ce que @ubombi a dit :

L'appel de la fonction try() interrompt l'exécution du code dans la fonction parent.; il n'y a pas de mot-clé de retour, mais le code renvoie en fait.

Dans Ruby, les procs et les lambdas sont un exemple de ce que fait try ... Un proc est un bloc de code que son instruction return ne renvoie pas du bloc lui-même, mais de l'appelant.

C'est exactement ce que fait try ... c'est juste un proc Ruby prédéfini.

Je pense que si nous devions emprunter cette voie, nous pourrions peut-être laisser l'utilisateur définir sa propre fonction try en introduisant proc functions

Je préfère toujours if err != nil , parce que c'est plus lisible mais je pense que try serait plus avantageux si l'utilisateur définissait son propre proc :

proc try(err *error, msg string) {
  if *err != nil {
    *err = fmt.Errorf("%v: %w", msg, *err)
    return
  }
}

Et puis vous pouvez l'appeler:

func someFunc() (string, error) {
  err := doSomething()
  try(&err, "someFunc failed")
}

L'avantage ici est que vous pouvez définir la gestion des erreurs dans vos propres termes. Et vous pouvez également créer un proc exposé, privé ou interne.

C'est aussi mieux que la clause handle {} dans la proposition Go2 d'origine car vous ne pouvez la définir qu'une seule fois pour l'ensemble de la base de code et non dans chaque fonction.

Une considération pour la lisibilité est qu'un func () et un proc () peuvent être appelés différemment, comme func() et proc!() afin qu'un programmeur sache qu'un appel proc peut en fait revenir hors du fonction d'appel.

@marwan-at-work, try(err, "someFunc failed") ne devrait-il pas être try(&err, "someFunc failed") dans votre exemple ?

@dpinela merci pour la correction, mise à jour du code :)

La pratique courante que nous essayons de remplacer ici est ce que le déroulement standard de la pile dans de nombreuses langues suggère dans une exception (et donc le mot "essayer" a été sélectionné...).
Mais si nous ne pouvions autoriser qu'une fonction (... try () ou autre) qui remonterait de deux niveaux dans la trace, alors

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
   }
} 

puis un code comme
f := try(os.Open(filename))
pourrait faire exactement comme le conseille la proposition, mais comme il s'agit d'une fonction (ou en fait d'une "fonction de gestionnaire"), le développeur aura beaucoup plus de contrôle sur ce que fait la fonction, comment elle formate l'erreur dans différents cas, utilisez un gestionnaire similaire tout autour le code pour gérer (disons) os.Open, au lieu d'écrire fmt.Errorf("erreur lors de l'ouverture du fichier %s ....") à chaque fois.
Cela forcerait également la gestion des erreurs comme si "try" n'était pas défini - c'est une erreur de compilation.

@guybrand Avoir un tel retour à deux niveaux return2 (ou "retour non local" comme le concept général est appelé dans Smalltalk) serait un bon mécanisme à usage général (également suggéré par @mikeschinkel dans # 32473) . Mais il semble que try soit toujours nécessaire dans votre suggestion, donc je ne vois pas de raison pour le return2 - le try peut simplement faire le return . Ce serait plus intéressant si on pouvait aussi écrire try localement, mais ce n'est pas possible pour les signatures arbitraires.

@griesemer

_"donc je ne vois pas de raison pour le return2 - le try peut juste faire le return ."_

Une raison — comme je l'ai souligné dans #32473 _(merci pour la référence)_ — serait d'autoriser plusieurs niveaux de break et continue , en plus de return .

Merci encore à tous pour tous les nouveaux commentaires ; c'est un investissement de temps important pour suivre la discussion et rédiger des commentaires détaillés. Et mieux encore, malgré les arguments parfois passionnés, cela a été un fil plutôt civil jusqu'à présent. Merci!

Voici un autre résumé rapide, cette fois un peu plus condensé ; excuses à ceux que je n'ai pas mentionnés, oubliés ou déformés. À ce stade, je pense que des thèmes plus larges émergent :

1) En général, l'utilisation d'une fonctionnalité intégrée pour la fonctionnalité try est ressentie comme un mauvais choix : étant donné qu'elle affecte le flux de contrôle, elle devrait être _au moins_ un mot-clé ( @carloslenz "préfère en faire une déclaration sans parenthèse"); try comme expression ne semble pas une bonne idée, cela nuit à la lisibilité ( @ChrisHines , @jimmyfrasche), ce sont des "retours sans return ". @brynbellomy a fait une analyse réelle de try utilisés comme identifiants ; il semble y en avoir très peu en pourcentage, il pourrait donc être possible d'emprunter la route des mots clés sans affecter trop de code.

2) @crawshaw a pris un certain temps pour analyser quelques centaines de cas d'utilisation de la bibliothèque std et est arrivé à la conclusion que try tel que proposé améliorait presque toujours la lisibilité. @jimmyfrasche est arrivé à la conclusion opposée .

3) Un autre thème est que l'utilisation defer pour la décoration des erreurs n'est pas idéale. @josharian souligne que les defer sont toujours exécutés au retour de la fonction, mais s'ils sont là pour la décoration d'erreur, nous ne nous soucions de leur corps que s'il y a une erreur, ce qui pourrait être une source de confusion.

4) Beaucoup ont écrit des suggestions pour améliorer la proposition. @zeebo , @patrick-nyt sont en charge de gofmt formatant des instructions simples if sur une seule ligne (et soyez satisfait du statu quo). @jargv a suggéré que try() (sans arguments) pourrait renvoyer un pointeur vers l'erreur actuellement "en attente", ce qui supprimerait le besoin de nommer le résultat de l'erreur juste pour y avoir accès dans un defer ; @masterada a suggéré d'utiliser errorfunc() la place. @velovix a relancé l'idée d'un argument à 2 try où le 2ème argument serait un gestionnaire d'erreurs.

@klaidliadon , @networkimprov sont en faveur des "opérateurs d'affectation" spéciaux comme dans f, # := os.Open() au lieu de try . @networkimprov a déposé une proposition alternative plus complète enquêtant sur ces approches (voir numéro 32500). @mikeschinkel a également déposé une proposition alternative suggérant d'introduire deux nouvelles fonctionnalités de langage à usage général qui pourraient également être utilisées pour la gestion des erreurs, plutôt qu'un try spécifique à l'erreur (voir le problème #32473). @josharian a relancé une possibilité dont nous avons discuté à GopherCon l'année dernière où try ne revient pas sur une erreur mais saute à la place (avec un goto ) vers une étiquette nommée error (alternativement , try peut prendre le nom d'un libellé cible).

5) Au sujet de try comme mot-clé, deux lignes de pensée sont apparues. @brynbellomy a suggéré une version qui pourrait alternativement spécifier un gestionnaire :

a, b := try f()
a, b := try f() else err { /* handle error */ }

@thepudds va un peu plus loin et suggère try au début de la ligne, donnant try la même visibilité qu'un return :

try a, b := f()

Les deux pourraient fonctionner avec defer .

@griesemer

Merci pour la référence à @mikeschinkel # 32473, il a beaucoup en commun.

En ce qui concerne

Mais il semble que try soit toujours nécessaire dans votre suggestion
Bien que ma suggestion puisse être implémentée avec "n'importe quel" gestionnaire et non un "build in/keyword/expression" réservé, je ne pense pas que "try()" soit une mauvaise idée (et donc je ne l'ai pas voté contre), j'essaie pour "l'élargir" - afin qu'il montre plus d'avantages, beaucoup s'attendaient "une fois que le go 2.0 est introduit"

Je pense que cela peut également être la source des "ambiances mixtes" que vous avez signalées dans votre dernier résumé - ce n'est pas "try () n'améliore pas la gestion des erreurs" - bien sûr, c'est "en attente de Go 3.0 pour résoudre une autre erreur majeure douleurs de manipulation" les personnes indiquées ci-dessus, semble trop longue :)

Je mène une enquête sur les "douleurs de la gestion des erreurs" (et sonne que certaines des douleurs sont simplement "je n'utilise pas de bonnes pratiques", alors que certaines que je n'imaginais même pas que les gens (venant pour la plupart d'autres langues) voudraient faire - de cool à WTF).

J'espère que je pourrai bientôt partager des résultats intéressants.

enfin -Merci pour le travail incroyable et la patience !

En regardant simplement la longueur de la syntaxe proposée actuelle par rapport à ce qui est disponible maintenant, le cas où l'erreur doit simplement être renvoyée sans la manipuler ou la décorer est le cas où le plus de commodité est gagnée. Un exemple avec ma syntaxe préférée jusqu'à présent :

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; }

Donc, différent de ce que je pensais auparavant, il suffit peut-être simplement de modifier go fmt, au moins pour le cas d'erreur décorée/traitée. Alors que pour le cas d'erreur, quelque chose comme try peut toujours être souhaitable en tant que sucre syntaxique pour ce cas d'utilisation très courant.

En ce qui concerne try else , je pense que les fonctions d'erreur conditionnelle comme fmt.HandleErrorf (édition : je suppose qu'elle renvoie nil lorsque l'entrée est nulle) dans le commentaire initial fonctionnent bien, donc en ajoutant else est inutile.

a, b, err := doSomething()
try fmt.HandleErrorf(&err, "Decorated "...)

Comme beaucoup d'autres ici, je préfère que try soit une déclaration plutôt qu'une expression, principalement parce qu'une expression modifiant le flux de contrôle est complètement étrangère à Go. Aussi parce que ce n'est pas une expression, il devrait être au début de la ligne.

Je suis également d'accord avec @daved que le nom n'est pas approprié. Après tout, ce que nous essayons de réaliser ici est une affectation protégée, alors pourquoi ne pas utiliser guard comme dans Swift et rendre la clause else facultative ? Quelque chose comme

GuardStmt = "guard" ( Assignment | ShortVarDecl | Expression ) [  "else" Identifier Block ] .

où Identifier est le nom de la variable d'erreur lié dans le Block . Sans clause else , revenez simplement de la fonction actuelle (et utilisez un gestionnaire de report pour décorer les erreurs si nécessaire).

Au départ, je n'aimais pas une clause else parce que c'est juste du sucre syntaxique autour de l'affectation habituelle suivie de if err != nil , mais après avoir vu certains des exemples, cela a du sens : utiliser guard rend l'intention plus claire.

EDIT : certains ont suggéré d'utiliser des choses comme catch pour spécifier d'une manière ou d'une autre différents gestionnaires d'erreurs. Je trouve else tout aussi viable sémantiquement parlant et c'est déjà dans la langue.

Bien que j'aime l'instruction try-else, qu'en est-il de cette syntaxe ?

a, b, (err) := func() else { return err }

L'expression try - else est un opérateur ternaire.

a, b := try f() else err { ... }
fmt.Println(try g() else err { ... })`

L'instruction try - else est une instruction if .

try a, b := f() else err { ... }
// (modulo scope of err) same as
a, b, err := f()
if err != nil { ... }

try intégré avec un gestionnaire optionnel peut être réalisé avec une fonction d'assistance (ci-dessous) ou sans utiliser try (non illustré, nous savons tous à quoi cela ressemble).

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
}

Tous les trois réduisent le passe-partout et aident à contenir la portée des erreurs.

Il offre le plus d'économies pour les try intégrés, mais cela présente les problèmes mentionnés dans le document de conception.

Pour l'instruction try - else , cela offre un avantage par rapport à l'utilisation if au lieu de try . Mais l'avantage est tellement marginal que j'ai du mal à le voir se justifier, même si j'aime bien ça.

Tous les trois supposent qu'il est courant d'avoir besoin d'un traitement d'erreur spécial pour des erreurs individuelles.

La gestion de toutes les erreurs peut également être effectuée dans defer . Si la même gestion des erreurs est effectuée dans chaque bloc else , c'est un peu répétitif :

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
}

Je sais certainement qu'il y a des moments où une certaine erreur nécessite un traitement spécial. Ce sont les exemples qui ressortent dans ma mémoire. Mais, si cela ne se produit, disons, que 1 fois sur 100, ne serait-il pas préférable de garder try simple et de ne pas utiliser try dans ces situations ? D'un autre côté, si c'est plutôt 1 fois sur 10, ajouter else /handler semble plus raisonnable.

Il serait intéressant de voir une distribution réelle de la fréquence à laquelle try sans else /handler vs try avec un else /handler serait utile, cependant ce ne sont pas des données faciles à recueillir.

Je veux développer le récent commentaire de @jimmyfrasche .

L'objectif de cette proposition est de réduire le passe-partout

    a, b, err := f()
    if err != nil {
        return nil, err
    }

Ce code est facile à lire. Cela ne vaut la peine d'étendre le langage que si nous pouvons parvenir à une réduction considérable du passe-partout. Quand je vois quelque chose comme

    try a, b := f() else err { return nil, err }

Je ne peux pas m'empêcher de penser que nous n'économisons pas tant que ça. Nous économisons trois lignes, ce qui est bien, mais d'après mes calculs, nous réduisons de 56 à 46 caractères. Ce n'est pas beaucoup. Comparer aux

    a, b := try(f())

qui passe de 56 à 18 caractères, une réduction beaucoup plus importante. Et bien que l'instruction try rende le changement potentiel de flux de contrôle plus clair, dans l'ensemble, je ne trouve pas l'instruction plus lisible. Bien que du côté positif, l'instruction try facilite l'annotation de l'erreur.

Quoi qu'il en soit, mon point est le suivant : si nous allons changer quelque chose, cela devrait réduire considérablement le passe-partout ou devrait être beaucoup plus lisible. Ce dernier est assez difficile, donc tout changement doit vraiment travailler sur le premier. Si nous n'obtenons qu'une réduction mineure du passe-partout, alors, à mon avis, cela ne vaut pas la peine d'être fait.

Comme d'autres, je voudrais remercier @crawshaw pour les exemples.

En lisant ces exemples, j'encourage les gens à essayer d'adopter un état d'esprit dans lequel vous ne vous inquiétez pas du flux de contrôle dû à la fonction try . Je crois, peut-être à tort, que ce flux de contrôle deviendra rapidement une seconde nature pour les personnes qui connaissent la langue. Dans le cas normal, je crois que les gens cesseront simplement de s'inquiéter de ce qui se passe en cas d'erreur. Essayez de lire ces exemples tout en glaciant sur try tout comme vous glaciez déjà sur if err != nil { return err } .

Après avoir tout lu ici, et après réflexion, je ne suis pas sûr de voir essayer même comme une déclaration quelque chose qui mérite d'être ajouté.

1. la raison semble être de réduire les erreurs de traitement du code de la plaque chauffante. À mon humble avis, cela "désencombre" le code mais cela ne supprime pas vraiment la complexité ; ça l' obscurcit juste. Cela ne semble pas une raison assez forte. Le feu vert" syntaxe magnifiquement capturée à partir d'un thread concurrent. Je ne ressens pas ce genre de sentiment "aha!" Ici. Cela ne me semble pas correct. Le rapport coût/bénéfice n'est pas assez important.

2. son nom ne reflète pas sa fonction. Dans sa forme la plus simple, ce qu'il fait est ceci : "si une fonction renvoie une erreur, le retour de l'appelant avec une erreur" mais c'est trop long :-) À tout le moins, un nom différent est nécessaire.

3. avec le retour implicite sur erreur de try, on a l'impression que Go recule à contrecœur dans la gestion des exceptions. C'est-à-dire que si A appelle être dans une garde try et B appelle C dans une garde try, et C appelle D dans une garde try, si D renvoie une erreur en effet vous avez causé un goto non local. C'est trop "magique".

4. et pourtant je crois qu'une meilleure façon peut être possible. Choisir essayer maintenant fermera cette option.

@ianlancetaylor
Si je comprends bien la proposition "essayez autrement", il semble que le bloc else soit facultatif et réservé à la gestion fournie par l'utilisateur. Dans votre exemple try a, b := f() else err { return nil, err } la clause else est en fait redondante, et l'expression entière peut être écrite simplement comme try a, b := f()

Je suis d'accord avec @ianlancetaylor ,
La lisibilité et le passe-partout sont deux préoccupations principales et peut-être la volonté de
la gestion des erreurs go 2.0 (bien que je puisse ajouter d'autres préoccupations importantes)

Aussi, que le courant

a, b, err := f()
if err != nil {
    return nil, err
}

Est très lisible.
Et puisque je crois

if a, b, err := f(); err != nil {
    return nil, err
}

Est presque aussi lisible, mais avait des "problèmes" de portée, peut-être un

ifErr a, b, err := f() {
    return nil, err
}

Cela ne ferait que le ; err != partie nulle, et ne créerait pas de portée, ou

De même

essayez a, b, euh := f() {
retour nul, erreur
}

Conserve les deux lignes supplémentaires, mais reste lisible.

Le mar. 11 juin 2019, 20:19 Dmitriy Matrenichev, [email protected]
a écrit:

@ianlancetaylor https://github.com/ianlancetaylor
Si je comprends bien la proposition "essayez autre chose", il semble que le bloc d'autre
est facultatif et réservé à la gestion fournie par l'utilisateur. Dans votre exemple
try a, b := f() else err { return nil, err } la clause else est en fait
redondant, et l'expression entière peut être écrite simplement comme try a, b :=
F()

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/32437?email_source=notifications&email_token=ABNEY4XPURMASWKZKOBPBVDPZ7NALA5CNFSM4HTGCZ72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXN3VDA#issuecomment-500 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/ABNEY4SAFK4M5NLABF3NZO3PZ7NALANCNFSM4HTGCZ7Q
.

@ianlancetaylor

Quoi qu'il en soit, mon point est le suivant : si nous allons changer quelque chose, cela devrait réduire considérablement le passe-partout ou devrait être beaucoup plus lisible. Ce dernier est assez difficile, donc tout changement doit vraiment travailler sur le premier. Si nous n'obtenons qu'une réduction mineure du passe-partout, alors, à mon avis, cela ne vaut pas la peine d'être fait.

D'accord, et considérant qu'un else ne serait que du sucre syntaxique (avec une syntaxe bizarre !), très probablement utilisé rarement, je m'en fiche un peu. Je préférerais toujours que try soit une déclaration.

@ianlancetaylor Faisant écho à @DmitriyMV , le bloc else serait facultatif. Permettez-moi de donner un exemple qui illustre les deux (et qui ne semble pas trop éloigné de la vérité en termes de proportion relative de blocs try gérés par rapport aux blocs non gérés dans le code réel):

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
}

Bien que le modèle try / else n'enregistre pas beaucoup de caractères sur le composé if , il le fait :

• unifier la syntaxe de gestion des erreurs avec le try non géré
• indiquer clairement en un coup d'œil qu'un bloc conditionnel gère une condition d'erreur
• donnez-nous une chance de réduire l'étrangeté de la portée dont souffrent les if composés

Les try non gérés seront probablement les plus courants, cependant.

@ianlancetaylor

Essayez de lire ces exemples tout en survolant, essayez comme vous l'avez déjà fait sur if err != nil { return err }.

Je ne pense pas que ce soit possible/équivalent. Manquant qu'un essai existe dans une ligne encombrée, ou ce qu'il enveloppe exactement, ou qu'il y ait plusieurs instances dans une ligne... Ce n'est pas la même chose que de marquer facilement/rapidement un point de retour et de ne pas se soucier des détails qui s'y trouvent.

@ianlancetaylor

Quand je vois un panneau d'arrêt, je le reconnais par sa forme et sa couleur plus qu'en lisant le mot imprimé dessus et en réfléchissant à ses implications plus profondes.

Mes yeux peuvent vitrer sur if err != nil { return err } mais en même temps, cela enregistre toujours clairement et instantanément.

Ce que j'aime dans la variante try -statement, c'est qu'elle réduit le passe-partout, mais d'une manière à la fois facile à masquer mais difficile à manquer.

Cela peut signifier une ligne supplémentaire ici ou là, mais c'est toujours moins de lignes que le statu quo.

@brynbellomy

1. Comment proposez-vous de gérer les fonctions qui renvoient plusieurs valeurs, comme :
   func createMergeCommit(r *repo.Repo, index *git.Index, remote *git.Remote, remoteBranch *git.Branch) (hachage, erreur) {
2. Comment garderiez-vous une trace de la ligne correcte qui a renvoyé l'erreur
3. rejetant le problème de portée (qui peut être résolu d'autres manières), je ne suis pas sûr

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
    } ...

n'est pas si différent en termes de lisibilité, mais (ou fmt.Errorf("error with getting head : %s", err.Error() ) vous permet de modifier et de donner facilement des données supplémentaires.

Ce qui est encore un bourrin, c'est le

1. avoir à revérifier ; erreur != néant
2. renvoyer l'erreur telle quelle si nous ne voulons pas donner les informations supplémentaires - ce qui, dans certains cas, n'est pas une bonne pratique, car vous dépendez de la fonction que vous appelez pour refléter une "bonne" erreur qui indiquera "ce qui s'est mal passé ", dans le cas des fonctions file.Open , close , Remove , Db, etc., de nombreux appels de fonction peuvent renvoyer la même erreur (nous pouvons discuter si cela signifie que le développeur qui a écrit l'erreur a fait du bon travail ou non... mais il arrive) - et ensuite - vous avez une erreur, enregistrez-la probablement à partir de la fonction qui a appelé
   " createMergeCommit", mais je ne peux pas le retracer jusqu'à la ligne exacte sur laquelle il s'est produit.

Désolé si quelqu'un a déjà posté quelque chose comme ça (il y a beaucoup de bonnes idées :P ) Que diriez-vous de cette syntaxe alternative :

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)

c'est-à-dire que vous avez un -> handler à droite d'un appel de fonction qui est appelé si l'erreur renvoyée != nil. Le gestionnaire est une fonction qui accepte une erreur en tant qu'argument unique et renvoie éventuellement une erreur (par exemple, func(error) ou func(error) error ). Si le gestionnaire renvoie une erreur nulle, la fonction continue, sinon l'erreur est renvoyée.

donc a := b() -> handler équivaut à :

a, err := b()
if err != nil {
  if herr := handler(err); herr != nil {
    return herr
  }
}

Maintenant, en tant que raccourci, vous pouvez prendre en charge un try intégré (ou un mot-clé ou un opérateur ?= ou autre) qui est l'abréviation de a := b() -> throw afin que vous puissiez écrire quelque chose comme :

func() error {
  a, b := try(f1())
  c, d := try(f2())
  e, f := try(f3())
  ...
  return nil
}() -> panic // or throw/fail/whatever

Personnellement, je trouve un opérateur ?= plus facile à lire qu'un mot-clé try/intégré :

func() error {
  a, b ?= f1()
  c, d ?= f2()
  e, f ?= f3()
  ...
  return nil
}() -> panic

note : ici, j'utilise throw comme espace réservé pour une fonction intégrée qui renverrait l'erreur à l'appelant.

Je n'ai pas commenté les propositions de gestion des erreurs jusqu'à présent parce que je suis généralement en faveur et j'aime la façon dont elles se dirigent. La fonction try définie dans la proposition et l'instruction try proposée par @thepudds semblent être des ajouts raisonnables au langage. Je suis convaincu que tout ce que l'équipe de Go proposera sera une bonne chose.

Je veux soulever ce que je considère comme un problème mineur avec la façon dont try est défini dans la proposition et comment cela pourrait avoir un impact sur les extensions futures.

Try est défini comme une fonction prenant un nombre variable d'arguments.

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

Passer le résultat d'un appel de fonction à try comme dans try(f()) fonctionne implicitement en raison de la façon dont plusieurs valeurs de retour fonctionnent dans Go.

D'après ma lecture de la proposition, les extraits suivants sont à la fois valides et sémantiquement équivalents.

a, b = try(f())
//
u, v, err := f()
a, b = try(u, v, err)

La proposition soulève également la possibilité d'étendre try avec des arguments supplémentaires.

Si nous déterminons en cours de route que le fait d'avoir une forme de fonction de gestionnaire d'erreurs fournie explicitement, ou tout autre paramètre supplémentaire d'ailleurs, est une bonne idée, il est trivialement possible de transmettre cet argument supplémentaire à un appel try.

Supposons que nous voulions ajouter un argument de gestionnaire. Il peut soit aller au début soit à la fin de la liste des arguments.

var h handler
a, b = try(h, f())
// or
a, b = try(f(), h)

Le mettre au début ne fonctionne pas, car (compte tenu de la sémantique ci-dessus) try ne serait pas en mesure de faire la distinction entre un argument de gestionnaire explicite et une fonction qui renvoie un gestionnaire.

func f() (handler, error) { ... }
func g() (error) { ... }
try(f())
try(h, g())

Le mettre à la fin fonctionnerait probablement, mais alors try serait unique dans le langage comme étant la seule fonction avec un paramètre varargs au début de la liste d'arguments.

Aucun de ces problèmes n'est un obstacle, mais ils font que try semble incompatible avec le reste de la langue, et donc je ne suis pas sûr que try soit facile à étendre à l'avenir comme le états de la proposition.

@magique

Avoir un gestionnaire est puissant, peut-être :
Je t'ai déjà déclaré h,

tu peux

var h handler
a, b, h = f()

ou

a, b, h.err = f()

si c'est une fonction comme:

h:= handler(err error){
 log(...)
 return ....
} 

Ensuite, il y a eu une suggestion de

a, b, h(err) = f()

Tous peuvent invoquer le gestionnaire
Et vous pouvez également "sélectionner" le gestionnaire qui renvoie ou ne capture que l'erreur (conitnue/break/return) comme certains l'ont suggéré.

Et donc le problème des varargs a disparu.

Une alternative à la suggestion else de @brynbellomy :

a, b := try f() else err { /* handle error */ }

pourrait être de prendre en charge une fonction de décoration immédiatement après le else :

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

try a, b := f() else decorate
try c, d := g() else decorate

Et peut-être aussi des fonctions utilitaires du genre :

decorate := fmt.DecorateErrorf("foo failed")

La fonction de décoration peut avoir la signature func(error) error et être appelée par try en présence d'une erreur, juste avant que try ne revienne de la fonction associée en cours d'essai.

Ce serait similaire dans l'esprit à l'une des "itérations de conception" précédentes du document de proposition :

f := try(os.Open(filename), handler)              // handler will be called in error case

Si quelqu'un veut quelque chose de plus complexe ou un bloc d'instructions, il peut utiliser à la place if (comme il le peut aujourd'hui).

Cela dit, il y a quelque chose de bien dans l'alignement visuel de try montré dans l'exemple de @brynbellomy dans https://github.com/golang/go/issues/32437#issuecomment -500949780.

Tout cela pourrait toujours fonctionner avec defer si cette approche est choisie pour une décoration d'erreur uniforme (ou même en théorie, il pourrait y avoir une autre forme d'enregistrement d'une fonction de décoration, mais c'est un point distinct).

Quoi qu'il en soit, je ne sais pas ce qui est le mieux ici, mais je voulais rendre explicite une autre option.

Voici l'exemple de @brynbellomy réécrit avec la fonction try , en utilisant un bloc var pour conserver le bel alignement que @thepudds a souligné dans https://github.com/golang/go/issues /32437#issuecomment -500998690.

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
}

C'est aussi succinct que la version try -statement, et je dirais tout aussi lisible. Étant donné que try est une expression, quelques-unes de ces variables intermédiaires pourraient être éliminées, au prix d'une certaine lisibilité, mais cela ressemble plus à une question de style qu'autre chose.

Cependant, cela soulève la question de savoir comment try fonctionne dans un bloc var . Je suppose que chaque ligne du var compte comme une déclaration distincte, plutôt que le bloc entier étant une seule déclaration, en ce qui concerne l'ordre de ce qui est attribué quand.

Ce serait bien si la proposition "essayer" indiquait explicitement les conséquences pour des outils tels que cmd/cover qui se rapprochent des statistiques de couverture de test en utilisant un comptage naïf des déclarations. Je crains que le flux de contrôle d'erreur invisible n'entraîne un sous-dénombrement.

@thepudds

essayez a, b := f() sinon décorer

C'est peut-être une brûlure trop profonde dans mes cellules cérébrales, mais cela me frappe trop en tant que

try a, b := f() ;catch(decorate)

et une pente glissante vers un

a, b := f()
catch(decorate)

Je pense que vous pouvez voir où cela mène, et pour moi, comparer

    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()

avec

    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()
    )

(ou même un hic à la fin)
La seconde est plus lisible, mais met l'accent sur le fait que les fonctions ci-dessous renvoient 2 vars, et nous en supprimons une comme par magie, en la collectant dans un "magic return err" .

    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
    }

définit au moins explicitement la variable à renvoyer et me laisse la gérer dans la fonction, quand je le souhaite.

J'ajoute juste un commentaire spécifique car je n'ai vu personne d'autre le mentionner explicitement, en particulier à propos de la modification gofmt pour prendre en charge le formatage sur une seule ligne suivant, ou toute variante :

if f() { return nil, err }

Je t'en prie, non. Si nous voulons une seule ligne if alors veuillez créer une seule ligne if , par exemple :

if f() then return nil, err

Mais s'il vous plaît, s'il vous plaît, s'il vous plaît, n'acceptez pas la salade de syntaxe en supprimant les sauts de ligne qui facilitent la lecture du code qui utilise des accolades.

J'aime souligner quelques points qui ont peut-être été oubliés dans le feu de la discussion :

1) L'intérêt de cette proposition est de faire en sorte que la gestion des erreurs courantes passe à l'arrière-plan - la gestion des erreurs ne doit pas dominer le code. Mais doit encore être explicite. Toutes les suggestions alternatives qui font ressortir encore plus la gestion des erreurs manquent le point. Comme @ianlancetaylor l' a déjà dit, si ces suggestions alternatives ne réduisent pas de manière significative la quantité de passe-partout, nous pouvons simplement rester avec les déclarations if . (Et la demande de réduction passe-partout vient de vous, la communauté Go.)

2) L'une des plaintes concernant la proposition actuelle est la nécessité de nommer le résultat d'erreur afin d'y avoir accès. Toute proposition alternative aura le même problème à moins que l'alternative n'introduise une syntaxe supplémentaire, c'est-à-dire plus de passe-partout (comme ... else err { ... } et autres) pour nommer explicitement cette variable. Mais ce qui est intéressant : si nous ne nous soucions pas de décorer une erreur et que nous ne nommons pas les paramètres de résultat, mais que nous avons toujours besoin d'un return explicite parce qu'il existe une sorte de gestionnaire explicite, cette instruction return devra énumérer toutes les valeurs de résultat (généralement zéro) car un retour nu n'est pas autorisé dans ce cas. Surtout si une fonction fait beaucoup de retours d'erreur sans décorer l'erreur, ces retours explicites ( return nil, err , etc.) s'ajoutent au passe-partout. La proposition actuelle, et toute alternative qui ne nécessite pas de return explicite, supprime cela. D'autre part, si l'on veut décorer l'erreur, la proposition actuelle _requiert_ que l'on nomme le résultat de l'erreur (et avec cela tous les autres résultats) pour avoir accès à la valeur de l'erreur. Cela a l'effet secondaire agréable que dans un gestionnaire explicite, on peut utiliser un retour nu et n'a pas à répéter toutes les autres valeurs de résultat. (Je sais qu'il y a des sentiments forts à propos des retours nus, mais la réalité est que lorsque tout ce qui nous intéresse est le résultat d'erreur, c'est une véritable nuisance d'avoir à énumérer toutes les autres valeurs de résultat (généralement zéro) - cela n'ajoute rien au compréhension du code). En d'autres termes, le fait de devoir nommer le résultat d'erreur afin qu'il puisse être décoré permet une réduction supplémentaire du passe-partout.

@magical Merci de l' avoir signalé. J'ai remarqué la même chose peu de temps après avoir publié la proposition (mais je ne l'ai pas évoquée pour ne pas semer la confusion). Vous avez raison de dire que tel quel, try ne peut pas être étendu. Heureusement, la solution est assez simple. (Il se trouve que nos propositions internes précédentes n'avaient pas ce problème - il a été introduit lorsque j'ai réécrit notre version finale pour publication et essayé de simplifier try pour qu'il corresponde plus étroitement aux règles de passage de paramètres existantes. - mais il s'avère qu'il est imparfait et surtout inutile - avantage de pouvoir écrire try(a, b, c, handle) .)

Une version antérieure de try définissait à peu près comme suit : try(expr, handler) prend une (ou peut-être deux) expressions comme arguments, où la première expression peut être à valeurs multiples (ne peut se produire que si l'expression est un appel de fonction). La dernière valeur de cette expression (éventuellement à valeurs multiples) doit être de type error , et cette valeur est testée par rapport à nil. (etc. - le reste vous pouvez imaginer).

Quoi qu'il en soit, le fait est que try n'accepte syntaxiquement qu'une ou peut-être deux expressions. (Mais il est un peu plus difficile de décrire la sémantique de try .) La conséquence serait ce code tel que :

a, b := try(u, v, err)

ne serait plus autorisé. Mais il y a peu de raisons pour que cela fonctionne en premier lieu : dans la plupart des cas (à moins que a et b ne soient des résultats nommés), ce code - s'il est important pour une raison quelconque - pourrait être réécrit facilement dans

a, b := u, v  // we don't care if the assignment happens in case of an error
try(err)

(ou utilisez une instruction if si nécessaire). Mais encore une fois, cela semble sans importance.

cette instruction de retour devra énumérer toutes les valeurs de résultat (généralement zéro) car un retour nu n'est pas autorisé dans ce cas

Un retour nu n'est pas autorisé, mais essayer le serait. Une chose que j'aime à propos de try (que ce soit en tant que fonction ou instruction) est que je n'aurai plus besoin de réfléchir à la façon de définir des valeurs sans erreur lors du renvoi d'une erreur, j'utiliserai simplement try.

@griesemer Merci pour l'explication. C'est aussi la conclusion à laquelle je suis arrivé.

Un bref commentaire sur try comme déclaration : comme je pense que l'on peut le voir dans l'exemple de https://github.com/golang/go/issues/32437#issuecomment -501035322, le try enterre le lede. Le code devient une série d'instructions try , ce qui masque ce que le code fait réellement.

Le code existant peut réutiliser une variable d'erreur nouvellement déclarée après le bloc if err != nil . Masquer la variable casserait cela, et ajouter une variable de retour nommée à la signature de la fonction ne le résoudra pas toujours.

Il est peut-être préférable de laisser la déclaration/affectation d'erreur telle quelle et de trouver un stmt de gestion des erreurs sur une ligne.

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)
}

Une sous-expression try pourrait paniquer, ce qui signifie qu'une erreur n'est jamais attendue. Une variante de cela pourrait ignorer toute erreur.

f(try g()) // panic on error
f(try_ g()) // ignore any error

L'intérêt de cette proposition est de faire en sorte que la gestion des erreurs courantes passe à l'arrière-plan - la gestion des erreurs ne doit pas dominer le code. Mais doit encore être explicite.

J'aime l'idée des commentaires listant try comme une déclaration. C'est explicite, toujours facile à passer sous silence (puisqu'il est de longueur fixe), mais pas si facile à passer sous silence (puisque c'est toujours au même endroit) qu'ils peuvent être cachés dans une ligne bondée. Il peut également être combiné avec le defer fmt.HandleErrorf(...) comme indiqué précédemment, mais il a le piège d'abuser des paramètres nommés afin d'envelopper les erreurs (ce qui me semble toujours être un hack intelligent. les hacks intelligents sont mauvais.)

L'une des raisons pour lesquelles je n'ai pas aimé try en tant qu'expression est qu'il est soit trop facile à passer sous silence, soit pas assez facile à passer sous silence. Prenons les deux exemples suivants :

Essayer comme expression

// 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")))),
))

Essayez comme déclaration

// 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)

Plats à emporter

Ce code est définitivement artificiel, je l'admets. Mais ce que je veux dire, c'est que, en général, try en tant qu'expression ne fonctionne pas bien dans :

1. Au milieu d'expressions encombrées qui ne nécessitent pas beaucoup de vérification d'erreurs
2. Instructions multilignes relativement simples nécessitant de nombreuses vérifications d'erreurs

Je suis cependant d'accord avec @ianlancetaylor sur le fait que commencer chaque ligne par try semble gêner la partie importante de chaque instruction (la variable en cours de définition ou la fonction en cours d'exécution). Cependant, je pense que parce qu'il se trouve au même endroit et qu'il a une largeur fixe, il est beaucoup plus facile de passer sous silence, tout en le remarquant. Cependant, les yeux de chacun sont différents.

Je pense aussi qu'encourager les one-liners intelligents dans le code est juste une mauvaise idée en général. Je suis surpris de pouvoir créer un one-liner aussi puissant que dans mon premier exemple, c'est un extrait qui mérite toute sa fonction car il en fait tellement - mais il tient sur une ligne si je ne l'avais pas effondré à plusieurs pour des raisons de lisibilité. Tout en une ligne :

fullContents := try(io.CopyN(os.Stdout, try(net.Dial("tcp", "localhost:"+try(r.ReadString("\n"))), try(strconv.Atoi(try(r.ReadString("\n"))))))

Il lit un port à partir d'un *bufio.Reader , démarre une connexion TCP et copie un nombre d'octets spécifié par le même *bufio.Reader vers stdout . Le tout avec gestion des erreurs. Pour un langage avec des conventions de codage aussi strictes, je ne pense pas que cela devrait vraiment être autorisé. Je suppose que gofmt pourrait aider avec ça, cependant.

Pour un langage avec des conventions de codage aussi strictes, je ne pense pas que cela devrait vraiment être autorisé.

Il est possible d'écrire du code abominable en Go. Il est même possible de le formater terriblement ; il n'y a que des normes et des outils solides contre cela. Go a même goto .

Lors des révisions de code, je demande parfois aux gens de décomposer des expressions compliquées en plusieurs instructions, avec des noms intermédiaires utiles. Je ferais quelque chose de similaire pour les try profondément imbriqués, pour la même raison.

Ce qui revient à dire : n'essayons pas trop d'interdire le mauvais code, au prix de déformer le langage. Nous avons d'autres mécanismes pour garder le code propre qui conviennent mieux à quelque chose qui implique fondamentalement un jugement humain au cas par cas.

Il est possible d'écrire du code abominable en Go. Il est même possible de le formater terriblement ; il n'y a que des normes et des outils solides contre cela. Allez même a goto.

Lors des révisions de code, je demande parfois aux gens de décomposer des expressions compliquées en plusieurs instructions, avec des noms intermédiaires utiles. Je ferais quelque chose de similaire pour les trys profondément imbriqués, pour la même raison.

Ce qui revient à dire : n'essayons pas trop d'interdire le mauvais code, au prix de déformer le langage. Nous avons d'autres mécanismes pour garder le code propre qui conviennent mieux à quelque chose qui implique fondamentalement un jugement humain au cas par cas.