Error and exception management for Go language projects

This is a creation in Article, where the information may have evolved or changed.

Recently encountered a friend asked me about the project error and abnormal management of things, but also many times with the team stressed the error and exception management concepts, so take advantage of today's motivation to write a Go language project error and exception management experience sharing.

First we need to clarify: what is wrong, what is an exception, and why it needs to be managed. Then is how to manage.

Errors and exceptions from the language mechanism above, is the difference between error and panic, put in other languages also, other languages do not have the error type, but there are errors, such as, no panic, but there are throw and so on.

They are two concepts at the language level, resulting in two different outcomes. If the program encounters an error and does not handle it, it may further cause a business error, such as paying the user more money, or further generating an exception, and if the program encounters an exception, the result is a process exception exit.

Should you handle all the error situations and catch all the exceptions in the project? I can only say that you can do this, but the effect is not too good. My reasons are:

1. If everything is processed and recorded, then important information may be submerged in the ocean of information.
2. The error that should not be handled is handled, it is easy to export the bug can not be exposed, until more serious errors to expose the problem, then the troubleshooting is very difficult, because it is not the first scene of the wrong.

Therefore, errors and exceptions can best be classified and managed according to certain rules, in the first time can expose errors and restore the scene.

For error handling, Erlang has a good concept called speed error, which is the first time a bug is exposed. Our project has been based on this design principle from Erlang to go. But the premise of applying this principle is to distinguish the two concepts of error and anomaly first.

Errors and exceptions have been mentioned above, from the language mechanism level is easier to distinguish them, but the language depends on the human, under what circumstances to use the wrong expression, under what circumstances with abnormal expression, there must be a set of rules, otherwise it is easy to appear all by the exception to do error treatment, it seems that Java project especially easy to appear such a design.

Here I first imagine a business where gamers buy gems with coins by buying buttons.

In the implementation of this business, the logic of the program will be further differentiated into the client logic and service-side logic, the client logic is further due to the different design methods differentiated into two structures: FAT client structure, thin client structure.

The rich client structure, has more local data and understands more business logic, so in the application of the FAT client structure, the above business will be implemented as follows: The client checks the number of coins in the cache, the number of coins is sufficient when the purchase button is available light state, the user clicks the Buy button after the client sends the purchase request to the server When the server receives the request, it verifies the number of coins of the user, if the number of coins is insufficient, throws an exception, terminates the request process and disconnects the client, if the number of coins is sufficient to further complete the gem purchase process, this does not continue to describe the normal process.

Because the normal client is the process of having one-step data validation, it is more reasonable to throw an exception than to return an error when the server receives an unreasonable request (the coin is not enough to buy a gem), because the request can only come from two clients: plug-ins or bugs. If you do not terminate the business process and disconnect the client by throwing an exception, the error of the program will be difficult to find in the first time and the attack behavior will be difficult to detect.

We look back at the design of thin client structure, thin client does not have too much state data and user data is not clear business logic, so the client design will be this: the user click on the purchase button, the client sends a purchase request, the service side received a request to check the number of coins, the number of insufficient to return an insufficient number of error codes, Sufficient quantity to continue to complete the business and return success information, the client receives the service side processing results, the interface to make a reflection.

In this structure, the shortage of copper coins has become a business logic within the scope of a failure, but can not be promoted to an exception, otherwise the less than the user of the penny purchase button will be wrong off the line.

So, exceptions and errors are converted to each other under different program structures, and we have no way to give a single sentence to all types of programs for all structures a uniform exception and error classification rules.

However, the classification of exceptions and errors can be traced. For example, the above mentioned thin client structure, the copper shortage is a business logic within the scope of a failure, it is a business error, such as the program logic to try to request a URL, up to three times, retry the process of three times the request failed is an error, retry to the third time, the failure is promoted to an exception.

So we can classify exceptions and errors: not terminating the program logic run is categorized as an error, terminating the program logic run as an exception.

Because the error does not terminate the logical run, so the error is part of the logic, such as the thin client structure mentioned above, the error of the copper coin is a logical branch that needs to be considered and processed in the process of business logic processing. The exception is something that should not be in the business logic, such as the FAT client structure mentioned above, the penny shortage is not part of the business logic to consider, so it should be an exception.

The classification of errors and anomalies need to be strengthened by certain thinking training, similar to object-oriented design, the technical implementation is over there, but to use the constant thinking training to keep the classification and summary, the above mentioned classification method hope can be used as a reference, We look forward to finding more and more effective ways to categorize.

Let's talk about the speed error and how to do it in the go language.

Quick Error My earliest contact was when I was doing ASP, and of course, the speed of Erlang is not exactly the same, and then there is no such a big name, but the idea of treating the anomaly is the same.

In the development of. NET projects, experienced programmers should know that can not casually re-throw, is the catch error again thrown, because the exception of the first scene will be destroyed, the stack trace information will be lost, because the outside finally get the exception stack trace information, Is the last throw of the exception of the stack trace information; second, can not casually try catch, casual catch is easy to export the exception is not exposed, upgrade to a more serious business vulnerability.

By the time of Erlang, we learned the concept of fast-error, simply: Let it hang. It is only when you hang up that you will know the error the first time, but Erlang's hanging, just the abnormal exit of the Erlang process, will not cause the entire Erlang node to exit, so it hangs at a lower level of influence.

In the Go Language project, although there is a goroutine similar to the Erlang process, but if the goroutine panic, and there is no recover, then the entire go process will exit unexpectedly. So we have to apply the fast-wrong design concept in Go language project, we should do some management to goroutine.

In our game server project, I put the goroutine after the results of the suspension divided into two categories: 1, after the suspension does not affect the other business or function, 2, hang off after the business can not be normal.

The first type of goroutine is typical: handling the goroutine of each player request, because each player has a goroutine connection, so hanging up will only affect a single player and will not affect the overall business.

The second type of goroutine typical: Database synchronization with the Goroutine, if it hangs, the data can not be synchronized to the database, the game if continue to run will only lead to data back, it is better to let the entire game exit unexpectedly.

Such a classification, it can be more clear which goroutine to do recover treatment, which should not do recover treatment.

So when doing recover processing, how to try to keep the first scene to help the group developers to troubleshoot the cause of the problem? In our project, error and stack trace information is usually recorded in the outermost recover, along with key business information such as user ID, source IP, request data, etc.

To this end, we also specially designed a library to format the output stack trace information and object information, project address: Http://github.com/funny/debug

The whole writing down to find than I expected a lot longer, so here I do a summary, help the group understand this article to express:

1. Errors and exceptions need to be categorized and managed, not generalize
2. Classification of errors and exceptions can be based on whether the business process is terminated as a standard
3. Errors are part of a business process, and exceptions are not
4. Do not randomly catch exceptions, not just catch them and re-throw them.
5. The Go language project needs to divide goroutine into two categories, dealing with exceptions differently
6. When you catch an exception, you need to keep the key data from the first scene as much as possible

The above is only for opinion, to stimulate, hope to help you.