Goroutines are a big part of the Go language, and we often need to do all kinds of coordination and communication between multiple goroutine.
So Go has a particularly unique thing, and it’s the context. You’ll see him at the first argument of various functions, and it’s already a standard.
Scenarios include but are not limited to.
- Relying on context to pass public contextual information.
- Asynchronous operations when using goroutine, relying on context to cancel or return errors, etc.
- Relying on context for cross-Goroutines management and control.
There are many different APIs for the standard library Context, today’s star is the Cancel behavior.
The API call in the code, as follows.
Combined with the use cases, as follows.
In the above program, when the function
operation1 is executed, assuming an error is returned, the
context.cancel method is executed, ending the
operation2 function that is blocking.
In this way, it’s a perfectly normal Go program. But there is a problem here, that is, after you cancel the context, you only know that it was canceled. What is the reason?
Why was it cancelled, nobody knows…?
It’s a pain in the ass. My friend in the company often see this kind of case, and finally we can only go through the logs or guess the logic according to the clues.
It is rather unreasonable.
Similar issues have been proposed before, that is, to “facilitate debugging where contexts are cancelled”, that is, to address the handling of cancelled scenarios.
After several years of discussion, @Sameer Ajmani came up with a new proposal “proposal: context: add APIs for writing and reading cancelation cause” to solve this problem.
Several new APIs will be added as follows.
After calling the
WithTimeoutCause methods, a
CancelCauseFunc is returned instead of a
The difference is that you can get the root cause of the cancelled error by passing in the corresponding Error, etc., and then calling the
That is, you can get both the status of the canceled (context.Canceled) and the corresponding error message (myError) to solve the scenario mentioned in the previous article.
In this article, we introduced a missing design scenario for Go’s most common standard library, Context. It is not enough to have a Context status code; in business design, status codes and error messages should be matched.
When this proposal is merged, I believe developers who have had similar experiences in the past can reduce some troubleshooting time.