background
As a relatively emerging language, Go can be said to be standing on the shoulders of giants. From the Go grammar, we can see that the designer has many serious thoughts about it. Among them, Error's treatment is a very iconic one.
It is worth noting that Error in Go has always been a controversial content. Many proposals are constantly being proposed and overturned, and even the official error library is constantly iterating in multiple versions. The content of this article is based on version 1.19.3 Go.
Evolution of Error in various languages
To understand why Error occupies a topic in Go, we need to first understand the evolution of Error in programming languages.
C language
In C language, developers need to make error judgments based on the return value of the function. Each function is a single return value, which is generally passed as an incoming parameter by passing a pointer. The return value is of type int, indicating success or failure.
Obviously at this stage, the language designer simply considers the error as an "exception" situation, and the developer judges the execution result of the function. In this case, there is not much information in the error. This will aggravate the developers' handling of errors.
C++
After entering the C++ era, language brought exception. An error will be thrown as a special case other than normal execution of a program. And developers can use try...catch... to specialize in exception handling.
This design pattern has a wide influence, and many languages, including Javascript, continue this design. Its characteristic is that developers can know where the error is thrown, but they cannot know exactly what exception will the caller throw.
The concept of Error in Go
In Go's Error, we can see the characteristics of two ERRORs.
1. Distinguish between Error and Exception
The first point is that Go really distinguishes Error from Exception from language design. Go's exception handling logic does not introduce exception and supports multiple parameter return, so developers can easily bring an object that implements an error interface in the function signature and hand it over to the caller for processing.
Usually if a function returns value and error, the developer needs to determine the error first, and then use the processing value to process the next logic. Common codes are as follows:
value, err := getSomething()
if err != nil{
// Handle errors return
}
// Logical processingIn addition, the panic mechanism was introduced in Go, which is not exactly the same as the exceptions in other languages. In other languages, when a program throws an exception, it is equivalent to throwing an exception to the developer for processing. Panic in Go is specifically designed to target truly unexpected and irrecoverable situations, such as index crossing, irrecoverable environmental problems, and stack overflow.
At the same time, GO also provides an interface to recover from panic - recover. But this does not mean that developers should use it as a try... catch... Instead, it should be regarded as the last chance for special handling after the program crash. In Go's design, once panic is triggered, it means that the program should exit. However, in some business scenarios, we may also have log reporting, log printing, information notification and other operations. At this time, you should consider using recover.
It's an interface
The second point is that Error is actually an ordinary interface in Go. It not only saves wrong information, but also provides a series of ways for developers to use. Therefore, developers can expand, nest and encapsulate new errors by themselves and provide customized error modules for projects.
From this point of view, Error is not a special type in Go like other languages. It is just a normal value, and developers can implement a new set of Error interfaces themselves. But more often, the official errors library can cover most scenarios.
Therefore, Go is not designed to define a new set of Error mechanisms. Instead, we are developing a set of Errors to handle in code logic. You don't have to fully abide by this set of specifications, but according to the summary of various practical development experiences, this design pattern of Go has indeed won the favor of many developers.
Sample code:
// Create an errornewErr := ("A Error")
//Judge error typeif (newErr, ) {
("file does not exist")
} else {
(err)
}
Summarize
The reason why Go has attracted so many fans since its birth. In addition to the mechanism of handling language, it is more about its design concept. And the error in this article is part of it. When we use Go to develop, in addition to coding according to the recommended specifications, we should also care about and understand its design. Only in this way can we write better works.
Further reading Official errors library documentation address:/errors
The above is the detailed explanation of the design concept and background evolution of Go language error. For more information about Go error design concept, please pay attention to my other related articles!