[Go language] Russ Cox responds "Why I am not leaving Python for Go"

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

Note: this is russ Cox explanation go [1] There are already translations on the web [2"

[ 1]https://plus.google.com/116810148281701144465/posts/iqaikawp6ce

[ 2]http://www.aqee.net/response-to-why-im-not-leaving-python-for-go/

Here are the translations:

I received a number of emails that referred to a recent article entitled "Why I won't give up Python invested Go " [1] blog post. In this article, the author says that Go is not good except for "error handling with return values", others are very good. I want to write something about why go uses the return value for error handling, which may be helpful to everyone.

Gothe rules of the language are function return errors, and these functions do notPanic[2]. If a file cannot be found,OS. Openreturns an error that does notPanicIf you are writing data to an interrupted network connection,Net. ConnSeries Type[3]of theWritefunction returns an error, they do notPanic. These states can be expected in such a program. You know that these operations may fail becauseAPIThe designer has clearly demonstrated this with the error returned.

On the other hand, there are some operations that are almost impossible to fail, and in that situation there is no way to notify the error or to continue execution, which appliesPanic. A typical example is if a program calculatesX[j], butJhas crossed the line, this part of the code will causePanic. Like such an unpredictablePanicis a serious one in the programBug, it kills the process by default. Unfortunately, this makes it difficult to write robust, error-proof server programs, such as the need to be able to handle occasional errorsHTTPrequests, while keeping the rest of the server running. To solve this problem, we have introducedRecover, it allows aGoroutinecan be taken from a number of function call frames.Panicin the recovery execution. However,Paniccauses at least one function call frame to be lost[4]. We designed it deliberately. Quoting the original message: "This proposal differs from the anomaly model that is normally controlled as a process, but this is a prudent decision." We don't want to encourage programmers likeJavalanguage as confusing errors and anomalies. "

panic Span style= "font-family: the song Body;" > and the wrong format string or an interrupted network connection? "The answer is that there is no in-band method in calculating x[j] [7]

The rule is simple: if your function is likely to fail anyway, it should return an error. When I call the other package 's function, if the function is very good, I don't have to worry about it panic, unless something really happens, even then it shouldn't be me.

one thing you have to realize:Gois designed for writing large software. We like to keep the program simple, not a large program written for a large number of programmers, to keep on maintaining costs. One of the temptations of exception-based error handling is that it works well for small programs. But in a large code base, for each line of code, every normal operation needs to consider whether they trigger an exception that needs to be handled. This is a major drag on productivity and engineering time. I'm writing a largePythonThe program is experiencing this problem. Must admit thatGoIt is not convenient for callers to return errors in the language, but they are clear about the possibility of errors in the program and type System. When a function returns an error, the applet may just want to print out the error and then exit the program, but a more elaborate program will often do different processing depending on the source of the error. In this case,Tryand theCatchprocessing is more verbose than an explicit error-return value. AlthoughPythonlanguage ofTenLine code withGolanguage to implement may indeed be more verbose, however,Gothe primary goal of language is not to writeTenthe line code of the program.

in the article about the pitfalls of using exceptions for error handling, Raymond Chen The article is the best I have ever seen:

Http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx

Http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx

One word: Go the language developer [8] think that the type of error is so important that we use it as a built-in type.

Note: Occasionally you will seePanicand theRecoverused as a function of some functionsGoto, likeCin the language.longjmpand thesetjmpthat. This is good, but it should only be used in your own Packagein, if your Packagethe caller needs to know the behavior, then you are wrong to use thePanicand theRecover.

[1]http://uberpython.wordpress.com/2012/09/23/why-im-not-leaving-python-for-go/

[2] Panic This means go An exception-handling mechanism for language that indicates a serious program error.

[3] net. Conn ' s net. Udpconn net. Tcpconn, net. Unixconn etc. column type

[4] in the event that Panic function, the remaining code is not executed, and the execution process jumps directly out of the current function.

[5] the original: In-band

[6] The original text of "in-band" is In-band, a communication term. If information can be obtained from the same channel, it is in-band (In-band); If you need to get information from another channel, it is out-of-band (Out-of-band). here Russcox borrowed to refer to the way to obtain information, because X[J] if there is an error, there is no way to set a variable or other statements on the syntax to get the error message directly, so there is no in-band method, and for the function, the data and error information can be obtained from the return value, So it's an in-band approach.

[7] The translator thinks there is no way to calculate X[j] when you get an error message while processing an incorrect formatted string or an interrupted network connection, you can get an error message through the function return value.

[8] the original: Go Developers , should be implemented for Go language of people rather than using Go language of the person.