Comment by cletus

I have mixed feelings about errors as return codes. Then again, I have mixed feelings about exceptions.

There are two general use cases for exceptions:

1. Unexpected (typically fatal) problems;

2. As an alternative to multiple return values.

(1) is things like out of memory errors. (2) is things like you're trying to parse a user input into a number and it fails. I despise (2) for exceptions. It means writing code like:

    try:
      f = float(someText)
    catch ValueError:
      # I just parsed you, this is crazy,
      # here's an exception, throw it maybe?

where this gets particularly irritating is when you start writing code like this:

    try:
      doSomething()
    catch ValueError:
      pass

I nearly always end up writing wrapper functions around that crap.

Java is worse for this because some libraries (including standard ones) abuse checked exceptions for this. I actually prefer:

    if f, err := strconv.ParseFloat(text); err != nil {
      // do something
    }

or even:

    f, _ := strconv.ParseFloat(text);

for this kind of scenario.

For the truly bad--typically fatal--error conditions and cleanup, IMHO defer/panic actually works quite well. I certainly prefer this:

    f := File.Open('foo')
    defer f.Close()
    // do stuff

to:

    try:
      f = open('foo')
      # do stuff
    finally:
      if f:
        f.close()

as Go puts the two relevant things together.

Don't get me wrong: I like Python too but I do think Go has a lot going for it and has a bright future.