Maison >développement back-end >Golang >Comment puis-je gérer efficacement les erreurs dans les abstractions multi-niveaux de Go ?

Comment puis-je gérer efficacement les erreurs dans les abstractions multi-niveaux de Go ?

DDD
DDDoriginal
2024-12-22 20:16:10486parcourir

How Can I Effectively Handle Errors in Go's Multi-Level Abstractions?

Gestion des erreurs dans les abstractions multi-niveaux dans Go

La gestion des erreurs dans les abstractions multi-niveaux peut devenir fastidieuse lorsque les erreurs sont transmises à plusieurs reprises au chaîne, entraînant des journaux en double et une perte de contexte.

Annotation Erreurs

Annoter les erreurs est une approche recommandée. Cela implique de créer une nouvelle valeur d’erreur qui enveloppe l’erreur d’origine, fournissant ainsi un contexte supplémentaire. Le package d'erreurs fournit les fonctions Wrap() et Cause() à cet effet.

Dans l'exemple donné :

// ObjectThreeHiggerLevel
func (oTh *ObjectThreeHiggerLevel) CheckObjectTwoIsReady() error {
    if err := oTh.ObjectTwoHigherLevel.CheckObjectOneIsReady(); err != nil {
        return errors.Wrap(err, "Object3 illegal state: Object2 is invalid")
    }
    return nil
}

L'ObjectThreeHiggerLevel annote l'erreur d'ObjectTwoHigherLevel avec un contexte supplémentaire.

Erreurs « d'extension »

Une approche alternative consiste à "étendre" les erreurs en utilisant fmt.Errorf(). Bien qu'il ne fournisse pas de fonctionnalités de déballage des erreurs, il vous permet de créer des messages d'erreur personnalisés avec un contexte supplémentaire :

// ObjectThreeHiggerLevel
func (oTh *ObjectThreeHiggerLevel) CheckObjectTwoIsReady() error {
    if err := oTh.ObjectTwoHigherLevel.CheckObjectOneIsReady(); err != nil {
        return fmt.Errorf("Object3 illegal state: %v", err)
    }
    return nil
}

Délégation ou gestion des erreurs

Lors de la gestion des erreurs , il est important de décider s'il faut les gérer ou les déléguer à un niveau supérieur. Si une erreur n'est pas gérée, elle doit être déléguée avec un contexte supplémentaire pour éviter de perdre des informations ou de provoquer des journaux en double.

Dans l'exemple :

// ObjectThreeHiggerLevel
func (oTh *ObjectThreeHiggerLevel) CheckObjectTwoIsReady() error {
    if err := oTh.ObjectTwoHigherLevel.CheckObjectOneIsReady(); err != nil {
        if err := oTh.HandleError(err); err != nil {
            // Error handling failed, log and return original error
            return errors.Wrapf(err, "Object3 failed to handle error: %v", err)
        }
        return nil
    }
    return nil
}

Dans cet exemple, HandleError() tente pour gérer l'erreur. En cas d'échec, l'erreur d'origine est encapsulée et renvoyée.

Éviter les journaux en double

Annoter ou étendre les erreurs avec le contexte garantit que lorsqu'une erreur se propage dans la pile, il contient toutes les informations nécessaires pour une journalisation et une gestion des erreurs significatives. Cela évite les journaux en double et aide à comprendre la cause première d'un problème.

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