Maison  >  Article  >  développement back-end  >  Est-ce une erreur d'utiliser des assertions de type pour la gestion des erreurs ?

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

WBOY
WBOYavant
2024-02-10 10:24:09895parcourir

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

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

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)

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!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer