Comment by NateDad | Hacker News Reader

Comment by NateDad | Hacker News Reader

Parent Full thread

I thought lack of exceptions was a deal killer for me, until I started using Go... and then I realized how much better multiple returns is. You never have to worry about your code suddenly exiting out of the middle of a function if you don't want it to. If something returns an error... it's just a value returned. Hi error! How's it going?

In languages with exceptions, potentially any function call you make could throw, and you don't know, because it could be 6 levels deep in the call stack. (Even Java's checked exceptions don't help, since someone down the line inevitably just rights "throws exception" and the screws everyone up the stack).

Go is really fast to pick up, it's pleasant to write code in, and yes... it's boring. I think that's it's biggest feature. It gets out of your way so you can produce a product. Why does the language need to be interesting? Isn't it more important that it can build interesting things quickly and reliably? Go does that.

It seems silly to have to check the error return code with an if for every method I call. Surely a try { } catch around a block makes more sense than littering my code with if (errorHappened) in every second line.

How do you know what failed, then? A try/catch around the entire function simply tells you "something failed". Often times that is not good enough in a real program. You can't handle the error, since you don't know what function call it came from, so you're probably just logging it and swallowing it.

It also means that you don't know how much of your code executed. Have you written that file to disk yet? Maybe you need to clean it up now? Is that socket still open? or maybe you didn't get that far in the code?

In code that cares about handling errors, you end up with a lot of try/catches around individual functions that you know can throw... this is no different than go's if err != nil code.

  try {
    v = ThisCanThrow()
  } catch (Exception ex) {
    // handle this specific failure
  }

  v, err := ThisCanError()
  if err != nil {
    // handle this specific failure
  }

Because Go forces you to handle the error at the site where it is produced, error handling ends up being much more robust and specific. You can't just "let 'em fly" and make someone else deal with random exceptions up the stack. This almost always produces better code in the end.

Believe me, I understand where you're coming from. I've been using exceptions for 13 years in production code. I initially skipped Go pretty much solely because of the lack of exceptions. But I am really glad I gave it a second chance, because, damn, it is good.

This is a fairly minor point: but I also like how idiomatic error handling in Go only indents the block that handles the problem.

Because of multiple returns, the normal flow of execution isn't indented. I find that this makes it easier to skim Go code in practice.

Thanks for the explanation. In most cases cleanup is handled in finally blocks and the unit of work fails if any of N calls fails, in most case it makes no difference which one failed. Where the difference does matter it's probably in a different method etc.

Your explanation does seem to make the case for this type of error seem somewhat sensible, maybe I'll give Go another try. Are methods which return errors and the types of errors returned clearly documented/visible?

Methods' declarations indicate which ones return an error value. E.g.:

    func Demo (s string) (string, error){...}

When called, that is guaranteed to return a string and an error value (OR nil).

It seems silly, but it's simple, powerful, and removes a large class of ambiguity from your programs.

Reply on news.ycombinator.com