Heim  >  Artikel  >  Backend-Entwicklung  >  Wie man mit Fehlern in Golang umgeht

Wie man mit Fehlern in Golang umgeht

青灯夜游
青灯夜游Original
2022-12-23 11:08:265832Durchsuche

Golang verfügt normalerweise über drei Fehlerbehandlungsmethoden: Sentinel Error, Fehlertypzusicherung und Aufzeichnungsfehler-Aufrufstapel. Der Fehlerwächter bezieht sich auf die Verwendung einer Variablen mit einem bestimmten Wert als Beurteilungsbedingung für den Fehlerverarbeitungszweig. Fehlertypen werden zur Weiterleitung der Fehlerbehandlungslogik verwendet und haben die gleiche Wirkung wie Fehlerwächter. Das Typsystem sorgt für die Eindeutigkeit von Fehlertypen. Die Fehler-Blackbox bezieht sich darauf, dem Fehlertyp nicht allzu viel Aufmerksamkeit zu schenken und den Fehler an die obere Ebene zurückzugeben, wenn Maßnahmen ergriffen werden müssen. Dabei sollten Aussagen über das Fehlerverhalten und nicht über den Fehlertyp gemacht werden.

Wie man mit Fehlern in Golang umgeht

Die Betriebsumgebung dieses Tutorials: Windows 7-System, GO Version 1.18, Dell G3-Computer.

golang bietet keinen ähnlichen Fehlerbehandlungsmechanismus wie try-catch. Es übernimmt die Fehlerbehandlung im C-Sprachstil auf der Entwurfsebene und gibt Fehlerinformationen über Funktionsrückgabewerte zurück. try-catch类似的错误处理机制,在设计层面采用了C语言风格的错误处理,通过函数返回值返回出错的错误信息,具体样例如下:

func ReturnError() (string, error) {
	return "", fmt.Errorf("Test Error")
}

func main() {
	val, err := ReturnError()
	if err != nil {
		panic(err)
	}
	fmt.Println(val)
}

上面的例子是一个基本的错误处理样例,生产环境中执行的调用栈往往非常复杂,返回的error也各式各样,常常需要根据返回的错误信息确定具体的错误处理逻辑。

Golang通常有如下的三种错误处理方式,错误哨兵(Sentinel Error)、错误类型断言(Error Type Asseration)和记录错误调用栈。

错误哨兵(Sentinel Error)

哨兵指的是用特定值的变量作为错误处理分支的判定条件,常见的应用场景有gorm中的gorm.RecordNotFounded和redis库里的redis.NIL

golang里可以对同类型变量进行比较,接口变量则比较接口指向的的指针的地址。因此,当且仅当error类型的变量指向同一地址时,此两种变量相等,否则都为不相等。

var ErrTest = errors.New("Test Error")

err := doSomething()
if err == ErrTest{
	// TODO: Do With Error
}

使用哨兵存在如下几个问题存在两个问题:

1、代码结构不灵活,分支处理只能使用==或者!=进行判定,长此以往,容易写出常意大利面条式的代码。

var ErrTest1 = errors.New("ErrTest1")
var ErrTest2 = errors.New("ErrTest1")
var ErrTest3 = errors.New("ErrTest1")
……
var ErrTestN = errors.New("ErrTestN")
……
if err  == ErrTest1{
	……
} else if err == ErrTest2{
	……
}else if err == ErrTest3{
	……
}
……
else err == ErrTestN{
	……
}

2、哨兵变量值不能被修改,否则会导致逻辑错误,上述golang写法的error哨兵可以被改变,可以通过如下方式解决:

type Error string

func (e Error) Error() string { return string(e) }

3、哨兵变量会导致极强的耦合性,接口新增error的吐出就会造成使用者相应修改代码新增的处理错误问题。

相比较上面的方案,错误哨兵还有一种更为优雅的方案,依赖于接口而非变量:

var ErrTest1 = errors.New("ErrTest1")

func IsErrTest1(err error) bool{
  return err == ErrTest1
}

错误类型

错误类型来路由错误处理逻辑,和错误哨兵有异曲同工的作用,由类型系统来提供错误种类的唯一性,使用方法如下:

type TestError {
}
func(err *TestError) Error() string{
	return "Test Error"
}
if err, ok := err.(TestError); ok {
	//TODO 错误分支处理
}

err := something()
switch err := err.(type) {
case nil:
        // call succeeded, nothing to do
case *TestError:
        fmt.Println("error occurred on line:", err.Line)
default:
// unknown error
}

相比较于哨兵,错误类型的不变性更好,且可以使用switch来提供优雅的路由策略。但是这使得使用方依旧无法避免对于包的过重依赖。

使用接口抛出更复杂,多样的错误,依旧需要改变调用方的代码。

错误黑盒(依赖错误接口)

错误黑盒指的是不过分关心错误类型,将错误返回给上层。当需要采取行动时,要针对错误的行为进行断言,而非错误类型。

func fn() error{
	x, err := Foo()
	if err != nil {
		return err
	}
}

func main(){
	err := fn()
	if IsTemporary(err){
		fmt.Println("Temporary Error")
	}
}

type temporary interface {
        Temporary() bool
}
 
// IsTemporary returns true if err is temporary.
func IsTemporary(err error) bool {
        te, ok := err.(temporary)
        return ok && te.Temporary()
}

通过这样的方式,1.直接就解耦了接口间的依赖,2. 错误处理路由和错误类型无关,而与具体行为有关,避免了膨胀的错误类型。

总结

错误哨兵和错误类型避免不了依赖过重的问题,只有错误黑盒能够将问题从确定错误类型(变量)的处理逻辑变为确定错误行为。因此推荐使用第三种方式来处理错误。

这里必要要加一句,黑盒处理,返回错误并不意味着对错误的存在不理会或者是直接忽略,而是需要在合适的地方优雅得处理。在这个过程中,可以通过errorsWrap

func authenticate() error{
	return fmt.Errorf("authenticate")
}

func AuthenticateRequest() error {
	err := authenticate()
	// OR logger.Info("authenticate fail %v", err)
	if err != nil {
		return errors.Wrap(err, "AuthenticateRequest")
	}
	return nil
}

func main(){
	err := AuthenticateRequest()
	fmt.Printf("%+v\n", err)
	fmt.Println("##########")
	fmt.Printf("%v\n", errors.Cause(err))
}

// 打印信息
authenticate
AuthenticateRequest
main.AuthenticateRequest
	/Users/hekangle/MyPersonProject/go-pattern/main.go:17
main.main
	/Users/hekangle/MyPersonProject/go-pattern/main.go:23
runtime.main
	/usr/local/Cellar/go@1.13/1.13.12/libexec/src/runtime/proc.go:203
runtime.goexit
	/usr/local/Cellar/go@1.13/1.13.12/libexec/src/runtime/asm_amd64.s:1357
##########
authenticate
Das obige Beispiel ist ein grundlegendes Beispiel für die Fehlerbehandlung. Der in einer Produktionsumgebung ausgeführte Aufrufstapel ist oft sehr komplex und die zurückgegebenen error sind ebenfalls unterschiedlich. Es ist oft notwendig, den spezifischen Fehler zu bestimmen Nachricht basierend auf den zurückgegebenen Fehlerinformationen.

Golang verfügt normalerweise über die folgenden drei Fehlerbehandlungsmethoden: Sentinel Error, Error Type Asseration und Recording Error Call Stack.

Error Sentinel (Sentinel Error)

Sentinel bezieht sich auf die Verwendung einer Variablen mit einem bestimmten Wert als Beurteilungsbedingung des Fehlerverarbeitungszweigs Zu den gängigen Anwendungsszenarien gehören gorm.RecordNotFounded in gorm und redis.NIL in der Redis-Bibliothek. Golang kann Variablen desselben Typs vergleichen, und Schnittstellenvariablen vergleichen die Adressen von Zeigern, auf die die Schnittstelle zeigt. Daher sind die beiden Variablen genau dann gleich, wenn die Variable vom Typ error auf dieselbe Adresse zeigt, andernfalls sind sie nicht gleich. rrreeeBei der Verwendung von Sentinel gibt es zwei Probleme: 🎜🎜1 Die Codestruktur ist nicht flexibel und die Verzweigungsverarbeitung kann nur mit == oder != bestimmt werden. Auf lange Sicht ist es einfach, Spaghetti-ähnlichen Code zu schreiben. 🎜rrreee🎜2. Der Wert der Sentinel-Variablen kann nicht geändert werden, da es sonst zu einem logischen Fehler kommt. Der Fehler-Sentinel in der oben genannten Golang-Schreibmethode kann auf folgende Weise behoben werden: 🎜rrreee🎜3. Die Sentinel-Variable führt zu einer extrem starken Kopplung, Schnittstelle Das Ausspucken neuer Fehler führt dazu, dass Benutzer den Code entsprechend ändern und neue Verarbeitungsfehlerprobleme hinzufügen. 🎜🎜Im Vergleich zur oben genannten Lösung bietet Error Sentinel eine elegantere Lösung, die auf Schnittstellen anstelle von Variablen basiert: 🎜rrreee

Fehlertyp

🎜Fehlertypen Routenfehlerverarbeitungslogik, die den gleichen Effekt wie Fehler-Sentinels hat. Die Verwendungsmethode ist wie folgt: 🎜rrreee🎜Im Vergleich zu Sentinels sind Fehlertypen invarianter und können verwenden switch, um elegante Routing-Strategien bereitzustellen. Dies macht es für Benutzer jedoch unmöglich, eine übermäßige Abhängigkeit von Paketen zu vermeiden. 🎜🎜Die Verwendung von Schnittstellen zum Auslösen komplexerer und vielfältigerer Fehler erfordert immer noch eine Änderung des Codes des Aufrufers. 🎜

Fehler-Blackbox (hängt von der Fehlerschnittstelle ab)

🎜Fehler-Blackbox bedeutet, dass man sich nicht allzu sehr um den Fehlertyp kümmert Zurückgeben des Fehlers an die obere Ebene. Wenn Maßnahmen erforderlich sind, machen Sie Aussagen über das Verhalten des Fehlers und nicht über die Art des Fehlers. 🎜rrreee🎜Auf diese Weise werden 1. Abhängigkeiten zwischen Schnittstellen direkt entkoppelt, 2. Das Routing der Fehlerbehandlung hat nichts mit Fehlertypen zu tun, sondern bezieht sich auf bestimmte Verhaltensweisen, wodurch die Erweiterung von Fehlertypen vermieden wird. 🎜

Zusammenfassung

🎜Fehlerwächter und Fehlertypen können das Problem der übermäßigen Abhängigkeit nicht vermeiden. Nur die Fehler-Blackbox kann das Problem durch die Bestimmung des Fehlertyps lösen. Variable) Die Verarbeitungslogik ändert sich, um das Fehlerverhalten zu ermitteln. Daher wird empfohlen, den dritten Weg zur Fehlerbehandlung zu verwenden. 🎜🎜Hier muss hinzugefügt werden: Black-Box-Verarbeitung, Fehlerrückgabe bedeutet nicht, das Vorhandensein von Fehlern zu ignorieren oder sie direkt zu ignorieren, sondern sie müssen an der entsprechenden Stelle ordnungsgemäß gehandhabt werden. In diesem Prozess können Sie Wrap von Fehler🎜,🎜 übergeben Zap🎜logging und andere Methoden zeichnen die Kontextinformationen des aufrufenden Links während des Prozesses der Fehlerrückgabe Schicht für Schicht auf. 🎜rrreee🎜【Verwandte Empfehlungen: 🎜Go-Video-Tutorial🎜, 🎜Programmierunterricht🎜】🎜

Das obige ist der detaillierte Inhalt vonWie man mit Fehlern in Golang umgeht. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn