Ça ce serait en tant que moyen de gestion d'erreurs. En Go le panic n'est pas utilisé pour cela.
Je ne dis pas que l'approche Go avec retours multiples pour la gestion des erreurs est meilleure ou non (c'est assez subjectif, vu le manque de consensus sur le sujet), mais c'est là une autre question. Étant donné le choix fait dans Go pour la gestion d'erreurs, les exceptions contrôlées, une solution complètement différente, conduiraient à une situation plutôt difficile où il faut considérer deux méthodes de gestion d'erreurs lorsqu'on lit du code.
Cherche panic dans la doc de https://golang.google.cn/pkg/bufio/ : bonjour pour savoir comment faire un code fiable avec des comportements comme Scan panics if the split function returns too many empty tokens without advancing the input.
Tel que je comprends la chose, un panic là signifie que la fonction de splitage qu'on a donné est incorrecte. Ça me semble être juste une façon ad hoc d'ajouter une détection de boucle infinie dans Scan (l'heuristique étant 100 itérations sans avancement : ça devrait écarter tous les cas licites en pratique, je ne vois pas trop pourquoi on pourrait avoir un avancement de zéro plus de une ou deux fois). Ce genre de cas d'utilisation de panic est extrêmement rare dans Go.
Je préférais moins subtil et plus fiable du type std::vector.
C'est moins subtil, oui. Fiable, les deux le sont, je dirais.
L'utilisation de slices permet souvent de gérer une fenêtre et donc d'avoir un code avec des indices plus simples (sans gérer d'offsets) et appliquer des fonctions facilement à une partie de tableau seulement. Perso je trouve que la courbe d'apprentissage vaut le coup, mais c'est subjectif. D'habitude on reproche à Go de trop sacrifier en expressivité en vue d'être simple : là on a une exception où un choix a été fait qui complique peut-être un peu la courbe d'apprentissage pour plus d'expressivité :-)
[^] # Re: Ouaiche
Posté par anaseto . En réponse au lien "Rust vs. Go: Why They’re Better Together". Évalué à 3.
Ça ce serait en tant que moyen de gestion d'erreurs. En Go le panic n'est pas utilisé pour cela.
Je ne dis pas que l'approche Go avec retours multiples pour la gestion des erreurs est meilleure ou non (c'est assez subjectif, vu le manque de consensus sur le sujet), mais c'est là une autre question. Étant donné le choix fait dans Go pour la gestion d'erreurs, les exceptions contrôlées, une solution complètement différente, conduiraient à une situation plutôt difficile où il faut considérer deux méthodes de gestion d'erreurs lorsqu'on lit du code.
Tel que je comprends la chose, un panic là signifie que la fonction de splitage qu'on a donné est incorrecte. Ça me semble être juste une façon ad hoc d'ajouter une détection de boucle infinie dans Scan (l'heuristique étant 100 itérations sans avancement : ça devrait écarter tous les cas licites en pratique, je ne vois pas trop pourquoi on pourrait avoir un avancement de zéro plus de une ou deux fois). Ce genre de cas d'utilisation de panic est extrêmement rare dans Go.
C'est moins subtil, oui. Fiable, les deux le sont, je dirais.
L'utilisation de slices permet souvent de gérer une fenêtre et donc d'avoir un code avec des indices plus simples (sans gérer d'offsets) et appliquer des fonctions facilement à une partie de tableau seulement. Perso je trouve que la courbe d'apprentissage vaut le coup, mais c'est subjectif. D'habitude on reproche à Go de trop sacrifier en expressivité en vue d'être simple : là on a une exception où un choix a été fait qui complique peut-être un peu la courbe d'apprentissage pour plus d'expressivité :-)