This is a creation in Article, where the information may have evolved or changed.
At noon, look at Daniel Morsing "The Go Scheduler", found another short article "Effective error handling in Go", the article is not long, but feel the error in the Go method summary is still relatively in place, This translation is for everyone's reference.
First, Introduction
One of the most criticized go languages is its error handling mechanism. If you explicitly check and process each error, this is probably a daunting one. You can try some of the methods listed here to prevent you from going into the wrong way of dealing with errors.
Second, handling errors in the indent area
When writing code using the Go language, the following error handling methods are preferred:
F, err: = OS. Open (PATH)
If err! = Nil {
Handle error
}
Do stuff
Instead of the following:
F, err: = OS. Open (PATH)
If Err = = Nil {
Do stuff
}
Handle error
By handling the error as described above, the code that handles the normal situation reads as if it were all coherent.
third, define your own error s
The first step to doing a proper error handling is to understand what error is. If you design a package that will cause some kind of error for some reason, your package user will be interested in the cause of the error. In order to meet the needs of users, you need to implement the error interface, simply do it like this:
Type Error string
Func (e Error) error () string {return string (E)}
Now, your package user can know whether your package caused this error by executing a type assertion:
result, err: = Yourpackage. Foo ()
If ype, OK: = Err. (Yourpackage. ERROR); OK {
Use ype to handle error
}
With this approach, you can also expose more structured error messages to your package users:
Type parseerror struct {
File *file
Error string
}
Func (OE *parseerror) Error () string {//: This is openerror in the original
Format error string here
}
Func parsefiles (Files []*file) error {
For _, F: = Range Files {
ERR: = F.parse ()
If err! = Nil {
Return &parseerror{//: This is openerror in the original
File:f,
Error:err. Error (),
}
}
}
}
In this way, your users will be able to know exactly which file is parsing the error. The meaning of the Go language error design from here reminds me of Rob Pike, a blog of the Great God: "Less is the number of levels of many")
But be careful when wrapping the error, and when you wrap an error, you may lose some information:
var c net. Conn
F, err: = DownloadFile (c, Path)
Switch e: = Err. (type) {
Default
This would get executed if err = = Nil
Case Net. Error:
Close connection, not valid anymore
C.close ()
Return E
Case ERROR:
If Err is Non-nil
return err
}
Do other things.
If you wrap the net. Error, the above code will not know that it is due to a network problem caused by the failure, will continue to use this invalid link.
There is a rule of thumb: if you use an external interface in your package, do not make any errors that are returned by methods in this interface, and users who use your package may be more concerned about these errors than the errors you have wrapped.
Iv. make the error a state
Sometimes, when you encounter an error, you may stop and so on. This is either because you will delay reporting errors, or because you know that if you follow this report, you will report the same mistake again.
An example of the first case is the BUFIO package. When a bufio. When reader encounters an error, it stops to maintain that state until the buffer has been emptied. Only then will it report an error.
An example of the second case is Go/loader. When you call it by some parameters to cause an error, it stops to maintain that state because it knows that you are likely to call it again using the same parameters.
v. Use functions to avoid duplication Code
If you have two pieces of repetitive error-handling code, you can put them in a function:
Func HandleError (c net. Conn, err Error) {
Repeated error handling
}
Func Dostuff (c net. Conn) Error {
F, err: = DownloadFile (c, Path)
If err! = Nil {
HandleError (c, Err)
return err
}
F, err: = Dootherthing (c)
If err! = Nil {
HandleError (c, Err)
return err
}
}
The following optimizations are implemented:
Func HandleError (c net. Conn, err Error) {
If Err = = Nil {
Return
}
Repeated error handling
}
Func Dostuff (c net. Conn) Error {
Defer func () {HandleError (c, err)} ()
F, err: = DownloadFile (c, Path)
If err! = Nil {
return err
}
F, err: = Dootherthing (c)
If err! = Nil {
return err
}
}
That's all. I know so much about the go language error handling.
, Bigwhite. All rights reserved.