Languages are a matter of fashion and style - and I'm not being rude, well perhaps about the fashion part. The point is there are features that fit with a language's style and ethos and there are features that don't. Recently the Go community rejected a little syntactic sugar that could have made error handling much easier.

Retrofitted language features can be a disaster as unexpected interactions are revealed over time, requiring the introduction of special cases. Languages are complex and subtle and you really need to take care before rushing in and adopting new ideas. Go is a language with a very distinctive style and approach to things, although it can be difficult to say exactly what it is. In my mind, Go is a simple language that rejects many of the shiny toys that other languages and their users value. Go isn't really object oriented. It isn't really a functional language. It doesn't do much that is outlandish, new or academic. It is a language with both feet on the ground which certainly fits with the image of a GOpher.

I have heard a theory that Go attracts programmers who really don't care much about the lack of features that other programmers find attractive. This means that your average Go programmer isn't much interested in structured exception handling or generics. They just want to write the code and have it as simple and as transparent as possible.

This brings us to Go's error handling. It is primitive, and this can be considered a good thing, but it is also verbose. Go functions return an error code and this has to be tested for:

f, err := os.Open(filename)
if err != nil {
	return …, err 
}

OK this is simple, but if you are writing a function that calls lots of functions you have little choice but to repeat the error handling for every call - and that's a lot of ifs. Yes, we have copy and paste, but that's how errors happen and someone has to read this code.

The solution proposed is to add a try function to be used with the existing defer statement:

f := try(os.Open(filename))

This brings the function to an end if there is an error and in turn this triggers any defer functions you might include. What this means is that, instead of lots of if statements, you can handle the error using a single error handler:

defer func() {
 if err != nil {	
 // no error may have occurred - check for it
	err = …	// wrap/augment error
 }
}()

Recall that a defer function is called when the function that contains it ends. It is usually employed as a cleanup operation but it is already used to deal with panics - a more fatal sort of Go error.

Overall I think the idea is elegant and worth implementing as it is a slight modification that fits in with existing features, but this does not seem to be the view of Gophers. Reading through the discussion of the idea doesn't seem to reveal a "killer" argument for not including it. Mainly the objections seem to be a general worry that it obfuscates the flow of control - which defer already does, and basically that there is nothing wrong with the straightforward way of doing the job with if statements:

The most important concern appears to be that try does not encourage good error handling style but instead promotes the "quick exit

Many people don't like the idea of a built-in, or the function syntax that comes with it because it hides a return.

For some, the status quo of explicit if statements is not a problem, they are happy with it

and so on.

It all seems like a storm in a teacup and the syntactic sugar seems good unless you like wearing a hair shirt - perhaps Gophers come with a built-in hair shirt. However, the Go team decided to postpone, or perhaps bin, the proposal:

Based on the overwhelming community response and extensive discussion here, we are marking this proposal declined ahead of schedule.

Could this be a reaction to the recent criticism of the Go project - that it was Google's Go and not the communities. Open source projects with a lot of involvement of big companies are at risk of this sort of accusation. Could it be that this is an attempt to be magnanimous and very visibly give in to community pressure - not that there is that much community pressure? By postponing their own proposal we are provided with proof that it is a community sensitive governance. Pressing on with the proposal would have confirmed that it is a Google project to anyone wanting to prove it even if it was the right thing to do.

I don't know about you, but I think that the Go project needs a Benevolent Dictator For Life who could see the sense in adding modern language features when they cost so little. I don't think this decision is good for Go and it is certainly not good for the future adoption of Go by programmers looking for a language with a little sugar.

More Information

https://github.com/golang/go/issues/32437#issuecomment-512035919

https://github.com/golang/go/issues/32437

Related Articles

Go Survey Shows Show Continuing Preference For Go

Go Survey Revelations

Go Developer Network Launched

Go 2 Details Revealed

Help Go Develop

Go 1.11 Adds WebAssembly Port

Go 1.10 Adds Automatic Caching

A Programmer's Guide To Go With Visual Studio Code

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info