Hacker News Reader

Comment by pcwalton | Hacker News Reader

If you call a function that returns nothing but an error and you ignore the return value, the Go compiler does not complain and you will ignore the error. Go doesn't always force you to handle errors.

Also, Go has exceptions: panic and recover. They are idiomatically not used in the same way, but it's not true that you know by looking at Go code whether each line will fail, because lots of language constructs can implicitly panic. (You gave an example of one: indexing a nil slice.)

View on HN

One major difference between panic and exceptions is that you can only catch it on a function exit boundary with defer and recover. There is no "try".

So really, you should think of panics more like Erlang's error handling, where a segment of the program (bounded by "recover") will just stop running, but can initiate the process of self repair.

The difference is that Erlang has process isolation: a panic is guaranteed not to mess up the state of any other process, because there is no shared state. This is what makes reliable self-repair possible. In Go, there is one giant shared mutable heap shared between all goroutines. So there is no guarantee that a panicked goroutine left the heap in an orderly state such that self-repair is possible.

Erlang actors and goroutines are very very different.

True. Although, panics do run defers, so with good coding practise it's possible to ensure that either you don't share things (but rather pass them around over channels) or things like locks are safely cleaned up.

> with good coding practise it's possible to ensure that either you don't share things

So is it in C, that's no argument.

Turing completeness, your argument is invalid.

But seriously, it's not just possible to be memory safe in Go, it's fairly easy. You basically have to remember to never lock without defer mutex.Unlock() unless it can't possibly panic, and to share data via channels such that it only ever has a unique "owner".

Personally I'd have much preferred full isolation, immutable data with threadsafe mutable references, and Clojure style "persistent" collections which can be treated as values. But Go didn't go down that route.

"All you have to do is call free with every malloc and always keep track of your array size. Geez, people, it's not that hard!"

Sorry, note my "pedantics:" note on the bottom. If you ignore errors then you're actively going against the idiomatic way to write Go. I never claimed it was compiler-enforced. I'm not arguing for or against either side either (compiler or non-compiler), I'm just trying to state facts.

It is true that panics exist, but panics generally represent non-recoverable errors that deserve to crash. They're very rarely bugs (except slice access, which I mentioned). In practice, in any Go systems I've written, panics have not been an issue and have really never occurred (except, again, slice access, which I mentioned).

Regarding your comment below (I can't comment because it is too deep): where did you quote me saying the compiler forces you to handle errors? It doesn't, and if I said that it is an error.

I don't know how people keep misreading my comments, so in all caps: THE GO COMPILER DOES NOT ENFORCE ERROR HANDLING AND I NEVER CLAIMED IT DID (in any of my comments).

As frou_dh points out below, Go does not force all errors to be handled (edit: to be clear, they don't even have to handle it with _ ). See this working example in the playground for reference: http://play.golang.org/p/IPDTG6Ub2b

Edit: The comment that you replied to said "Go does not force you to handle errors." Your comment said "True but it's not idiomatic." My reply was meant to show that it's very easy to ignore errors in code that is not obviously un-idiomatic. Also, note that in your grandparent comment, you stated, "The PRIMARY reason Go is so reliable is also a reason many people hate go: you _have_ to handle every error." In my link, however, the error goes unhandled.

It's idiomatic in every language to handle errors, Go is not unique there.

I disagree. It's not idiomatic in, say, Python, to catch every possible exception, only the specific ones that the programmer thinks are likely to occur in practice.

> Sorry, note my "pedantics:" note on the bottom. If you ignore errors then you're actively going against the idiomatic way to write Go.

Just wait when Go spreads into the enterprise. You will see _ everywhere.

I'd love to see a "go vet" check or the like that complains if you implicitly discard an error return (but can be silenced by explicitly assigning it to _).

That still gives you a way to do odd things, but you'd have to explicitly choose to be odd. And since it's a check rather than a new language rule, old code still compiles.

https://github.com/kisielk/errcheck

Fantastic! Really glad to find this.

Ohh, thanks.

As I don't program in Go this might be wrong, but doesn't the programmer have to tell the Go compiler to ignore the error by using the _ variable thing?

In that sense Go is still forcing the programmer to handle the error and it is the programmer who is deciding to ignore it.

I can see making the programmer do nothing more than mark the error as ignored still forces the programmer to think about the error and as such adds some value.

Unless you ignore all returned values:

   func Something() (a, bunch, of, stuff) {
      // stuff
   }

   ...
   _, _, _, _ = Something()
   Something()

Both are valid.

Thanks for that.

I would have though that in a language all about error checking this would not be allowed:

    Something()

But there you go, I've learnt something new about Go.

> in a language all about error checking

Go is not one such language, that's one of the numerous go myths completely disconnected from reality.

Reply on news.ycombinator.com