Profile

Cover photo
Go+
1,066 followers|361,637 views
AboutPostsPhotosVideos

Stream

Go+

Shared publicly  - 
14
3
Skip Tavakkolian's profile photoHenrik Thuesen's profile photoKen Jones's profile photojia zou's profile photo
 
wish there was a - button
Add a comment...

Go+

Shared publicly  - 
5
1
zheng ying's profile photoAlessandro Baffa's profile photo
 
Add a comment...

Go+

Shared publicly  - 
 
 
I wish you run 2013 in four goroutines and accomplish everything just in one quarter! My bag is full of new packages, features, compiler and runtime improvements! Happy and concurrent 2013! Go go go!
                                 - Santa Gopher
10
1
Add a comment...

Go+

Shared publicly  - 
3
Add a comment...

Go+

Shared publicly  - 
 
A good read about the reasons behind Go's error handling conventions.
 
I've gotten a fair amount of mail about a recent blog post titled "Why I'm not leaving Python for Go" [1], in which the author says that Go is great except that "errors are handled in return values". I thought it would help to write a little about why this is.

In Go, the established convention is that functions return errors; they don't panic. If a file isn't found, os.Open returns an error; it doesn't panic. If you write to a broken network connection, the net.Conn's Write method returns an error; it doesn't panic. These conditions are expected in those kinds of programs. The operation is likely to fail, and you knew that going in, because the API designer made it clear by including an error result. 

On the other hand, there are some operations that are incredibly unlikely to fail, and the context is such that there is no way to signal the failure, no way to proceed. These are what panic is for. The canonical example is that if a program evaluates x[j] but j is out of range, the code panics. An unexpected panic like this is a  serious bug in the program and by default kills it. Unfortunately, this makes it difficult to write robust, defensive servers that can, for example, cope with the occasional buggy HTTP request handler while keeping the rest of the server up and running. To address that, we introduced recover, which allows a goroutine to recover from a panic some number of call frames below. However, the cost of a panic is the loss of at least one call frame from the stack. We did this intentionally. To quote from the original mail: "This proposal differs from the usual model of exceptions as a control structure, but that is a deliberate decision.  We don't want to encourage the conflation of errors and exceptions that occur in languages such as Java."

The post I mentioned at the start asks "why is an array out of bounds any more cause for panic than a bad format string or a broken connection?" The answer is that there is no in-band way to report the error during the evaluation of x[j], while there is an in-band way to report an error in a bad format string or a broken connection. (The format string decision is interesting by itself but orthogonal to this discussion.)

The rule is simple: if your function is in any way likely to fail, it should return an error. When I'm calling some other package, if it is well written I don't have to worry about panics, except for, well, truly exceptional conditions, things I shouldn't be expected to handle.

One thing you have to keep in mind is that the target for Go is programming in the large. We like to keep programs concise, but not at an increased maintenance cost for big programs worked on by large numbers of programmers. The seductive thing about exception-based error handling is that it works great for tiny examples. But diving into a large code base and having to worry about whether every single line might, in ordinary operation, trigger an exception worth handling is a significant drag on productivity and engineer time. I have had this problem myself finding my way around large Python programs. The error returns used by Go are admittedly inconvenient to callers, but they also make the possibility of the error explicit both in the program and in the type system. While simple programs might want to just print an error and exit in all cases, it is common for more sophisticated programs to react differently depending on where the error came from, in which case the try + catch approach is actually more verbose than explicit error results. It is true that your 10-line Python program is probably more verbose in Go. Go's primary target, however, is not 10-line programs.

Raymond Chen's articles are the best exposition I've seen about the pitfalls of trying to do error handling with exceptions:
http://blogs.msdn.com/b/oldnewthing/archive/2004/04/22/118161.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2005/01/14/352949.aspx
Suffice it to say that the Go developers agree: error is so important we made it a built-in type.

Russ

P.S. Occasionally you see panic and recover used as a kind of non-local goto, similar to longjmp and setjmp in C. This is fine too, but only as an internal detail of your package. If callers need to know, you're still doing it wrong.

[1] http://uberpython.wordpress.com/2012/09/23/why-im-not-leaving-python-for-go/
5
1
Joseph Burchett's profile photo
Add a comment...
In their circles
245 people
Have them in circles
1,066 people
Jay Graves's profile photo
Saul Caganoff's profile photo

Go+

Shared publicly  - 
 
 
Our experience with Go at +Iron.io after two years in production. #golang  

+Evan Shaw +Rob Pike +Derek Collison +Travis Reeder
13
2
苟常兴's profile photoDouglas Fils's profile photo
Add a comment...

Go+

Shared publicly  - 
 
 
http://www.meetup.com/golangsf/events/96043202/

Hosting a virtual meetup for February so that we can get even more great speakers involved. Will be using Google Hangout on Air. We'll create the event page in a bit with details on joining in directly and/or justing viewing live.

Have the event listed for 90 minutes but will look to keep it to 60min. Time is set so people on the east coast and elsewhere can join in. Can adjust that time going forward. Need people to give lightning presentations on their use of Go in production. Will provide general format.

 

Agenda:

5:00pm Start (pacific time)

5-minute: Go in Production 1
5-minute: Go in Production 2
Main Talk: Patrick Crosby, StatHat - Go thoughts and more
6:00/6:15pm Wrap


Main Talk:

Patrick Crosby will talk about their use of Go at Stathat. (More details to come.)
2
bahi Eldin's profile photo
 
love is soul of the life
Add a comment...

Go+

Shared publicly  - 
 
 
Thought I'd get a community going for Go developers.  
Go+
Go Community for Golang Developers
View community
1
Add a comment...

Go+

Shared publicly  - 
 
 
Wasn't it Ken Thompson that said in Google I/O that we'd know that Go is successful when people start writing viruses (his words iirc) using it?

Since Go doesn't require a runtime installation, has an excellent networking and encryption library and is definitely learnable by even the most stupid malware author, I bet it's gonna be very "successful" in this area.

(via the go weekly newsletter)

UPDATE: He was quoting someone else. It's not necessarily his opinion I guess. And I can't find the original quote.

Google I/O 2012 - Meet the Go Team 

44:38

KEN THOMPSON: "Somebody said, I think in a Turing lecture, not me, that the popularity of a language is guaranteed when you get your first virus in that language"

#golang
2
1
Add a comment...

Go+

Shared publicly  - 
 
 
Go 1.0.3 is out, with less bugs and better docs. Yay!
3
Add a comment...

Go+

Shared publicly  - 
 
A Go web framework, looks nice!

via +Gabriel Guzman 
9
1
Add a comment...
People
In their circles
245 people
Have them in circles
1,066 people
Jay Graves's profile photo
Saul Caganoff's profile photo
Story
Tagline
News, tips and discussions for Go (golang) developers.
Introduction
Go+ is the place to get all the latest news and information on happenings in the Go space and to have intelligent discussions about those happenings.

How do I submit news?

First, add Go+ to your circles. Then post the news to your Google+ stream and share it directly with us by adding +Go+ to the recipients. 

If you want your name to be publicly visible beside the post, be sure you shared it with the Public too. If you don't want your name to show up with the post, just share it with us directly without adding Public to the recipients.