Maison > développement back-end > Golang > le corps du texte

Est-ce une erreur d'utiliser des assertions de type pour la gestion des erreurs ?

WBOY
Libérer: 2024-02-10 10:24:09
avant
895 Les gens l'ont consulté

Est-ce une erreur dutiliser des assertions de type pour la gestion des erreurs ?

L'utilisation d'assertions de type pour la gestion des erreurs est une pratique courante, mais qu'il s'agisse d'une erreur ou non dépend de la situation. Les assertions de type peuvent être utilisées pour vérifier que les types de paramètres transmis répondent aux attentes, détectant ainsi rapidement les erreurs dans le code. Cependant, cela peut poser des problèmes si la gestion des erreurs repose sur des assertions de type et ignore d'autres exceptions possibles. Par conséquent, lorsque vous utilisez des assertions de type pour la gestion des erreurs, vous devez prendre en compte de manière globale la logique et la fiabilité du code et vous assurer que diverses exceptions sont correctement gérées pour garantir la stabilité et la maintenabilité du code.

Contenu de la question

Je me demande pourquoi la gestion des erreurs de style d'assertion switch + type n'est pas davantage utilisée/recommandée dans Golang. Qu'est ce qui ne va pas avec ça? Ou est-ce que la communauté ne s’en soucie tout simplement pas ?

Par exemple le code suivant :

if err != nil {
    if errors.as(err, &queryerr{}) {
        log.println("query error : ", err)
        return http.statusinternalservererror
    } else if errors.as(err, &querydataextractionerr{}) {
        return http.statusnotfound
    } else {
        log.println(err.error())
        return http.statusinternalservererror
    }
}
Copier après la connexion

peut s'écrire :

if err != nil {
    switch err.(type) {
    case QueryErr:
        log.Println("query error : ", err)
        return http.StatusInternalServerError
    case QueryDataExtractionErr:
        return http.StatusNotFound
    default:
        log.Println(err.Error())
        return http.StatusInternalServerError
    }
}
Copier après la connexion

Workaround

le commutateur de type est techniquement correct. Cependant, il existe des commutateurs de type incorrect qui peuvent mal interpréter les erreurs encapsulées. Par exemple :

err:=io.EOF
err1 := fmt.Errorf("Unexpected error: %w",err)
Copier après la connexion

En plus, err1.(io.eof) 会失败,但 errors.is(err1,io.eof) ne le fera pas.

Par conséquent, vous devez utiliser errors.iserrors.as pour tester si l'erreur que vous avez sous la main contient l'erreur que vous recherchez.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

source:stackoverflow.com
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal
À propos de nous Clause de non-responsabilité Sitemap
Site Web PHP chinois:Formation PHP en ligne sur le bien-être public,Aidez les apprenants PHP à grandir rapidement!