Hacker News Reader

Comment by trailfox | Hacker News Reader

Lack of exception handling is the biggest reason I haven't used Go for much. The other reasons are that it's just so plain/boring (yes, I know that's subjective), nothing about the syntax is interesting. Learning go is like eating cardboard. The other issues are that IDE support is very primitive and that Java and Scala are both faster and better supported in terms of tooling. Go seems rather nice, just very boring and not very compelling vs. many other tools.

View on HN

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.

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).

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.

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

> Lack of exception handling is the biggest reason I haven't used Go for much.

Go does exception handling with panic, recover and its reflection syntax.

So if I'm reading from a file I should use panic recover and not return code checking?? That's not what I've seen in the docs.

You seem to be missing the difference between "can you do it" and "should you do it". The reason that you should not is because doing so is not idiomatic Go. You are completely able to do so though.

Using panic and recover is strongly discouraged, and in the rare cases where it makes the code significantly simpler, panics should never cross package boundaries (which is to say, you should never have a public API that can panic, unless you fully expect the panic to take down the process).

Using panics for control flow or having panics cross library boundaries is strongly discouraged, otherwise they are fine. Go's own standard library uses them internally in several places.

Even then discouraging panics is very different from not having them.

Reply on news.ycombinator.com