4 ms·

Rob Pike made an interesting comment at the q&a for Gophercon I believe. Basically saying that error handling isn't anything special and he didn't want to creat

by kyrra 12y ago

Rob Pike made an interesting comment at the q&a for Gophercon I believe. Basically saying that error handling isn't anything special and he didn't want to create special syntax for handling error cases. Instead the syntax of the entire language is at your disposal to deal with errors. It was sort of a quick answer, so not really detailed. As well, panic/recover is there if you would prefer that, but err seems to work just fine.

oelmekki 12y ago
I got Pike's point on that, and love go overall, but this is really the topic on which I can't agree. The biggest problem with that is that throwing exceptions has a purpose : it makes errors interrupt program by default. With errors in go, that's the reverse : errors are ignored by default. Maybe it's just I'm too new in go, but I feel like I'd rather have my errors taken cautiously by default, with the possibility to ignore them (catch) than having to use variable and put if statement everywhere I care about errors (which pretty much means everywhere, in my current design style). Am I missing something, here, than can allow to avoid this verbosity ? (as for panic / recover, that's good for functions you implement yourself, but you still have to deal with errors from core / lib functions).
- Matrixik 12y ago
  > Maybe it's just I'm too new in go, but I feel like I'd rather have my errors taken cautiously by default, with the possibility to ignore them (catch) than having to use variable and put if statement everywhere I care about errors (which pretty much means everywhere, in my current design style). That's what you should do. > With errors in go, that's the reverse : errors are ignored by default. To ignore errors in Go you need to explicitly ignore them because most functions return error.
  - oelmekki 12y ago
    > To ignore errors in Go you need to explicitly ignore them because most functions return error. What. If user has to write something explicitly, then it's not a default. That's pretty much the definition of "default". Or else, C has garbage collection, you just have to write it (and you explicitly ignore proper memory management by not writing it).
  - NateDad 12y ago
    So, most functions return two things - output data and an error. You have to assign both to something, like this: data, err := foo() and go forces you to use variables somehow, or it'll give you a compile time error, so you can't just assign it and never look at it. There are some functions which only return an error, and yes, for those, you can simply not assign the result to anything. However, in general, you should be suspicious of functions that get called that don't seem to return anything. Can they really never fail? Note that there are linters which will warn you if you are ignoring errors (google errcheck, I don't have the URL handy). Yes there's a lot of error checking code in Go, but that's a good thing. It's explicit, and it makes you actually think about the error case. My Go programs are WAY more robust than my programs from other languages.
    - oelmekki 12y ago
      Forcing you to think about your errors is a good point, there's nothing more painful than discovering that an exception is thrown on production. I still feel it's getting in the way of the "Go allows you to be more productive" stance, though. Also, it makes it very dangerous for people not rigorous enough that will not take enough care of their errors. Granted, "it allows bad developers to do bad things" should not be an argument, but I wouldn't be surprised we hear in a few years of big fails that will be imputed to go error handling (with headlines like "Foo.com tragic fail was due to go forgetful position on handling errors").
      - NateDad 12y ago
        Go is not intended to be a fast and loose "bang it out in an afternoon" language. If you're comfortable with the language, then you can be really productive in it, but that includes error handling. You have to handle errors, that's like 50% of programming. I really doubt you'll see headlines like that. Why would you not see the same thing for code that doesn't handle exceptions in other languages? They're far more invisible than Go's errors, which are right there in the method signature.
        oelmekki 12y ago

by kyrra 12y ago

oelmekki 12y ago

I got Pike's point on that, and love go overall, but this is really the topic on which I can't agree. The biggest problem with that is that throwing exceptions has a purpose : it makes errors interrupt program by default. With errors in go, that's the reverse : errors are ignored by default. Maybe it's just I'm too new in go, but I feel like I'd rather have my errors taken cautiously by default, with the possibility to ignore them (catch) than having to use variable and put if statement everywhere I care about errors (which pretty much means everywhere, in my current design style). Am I missing something, here, than can allow to avoid this verbosity ? (as for panic / recover, that's good for functions you implement yourself, but you still have to deal with errors from core / lib functions).

Matrixik 12y ago
> Maybe it's just I'm too new in go, but I feel like I'd rather have my errors taken cautiously by default, with the possibility to ignore them (catch) than having to use variable and put if statement everywhere I care about errors (which pretty much means everywhere, in my current design style). That's what you should do. > With errors in go, that's the reverse : errors are ignored by default. To ignore errors in Go you need to explicitly ignore them because most functions return error.
- oelmekki 12y ago
  > To ignore errors in Go you need to explicitly ignore them because most functions return error. What. If user has to write something explicitly, then it's not a default. That's pretty much the definition of "default". Or else, C has garbage collection, you just have to write it (and you explicitly ignore proper memory management by not writing it).
- NateDad 12y ago
  So, most functions return two things - output data and an error. You have to assign both to something, like this: data, err := foo() and go forces you to use variables somehow, or it'll give you a compile time error, so you can't just assign it and never look at it. There are some functions which only return an error, and yes, for those, you can simply not assign the result to anything. However, in general, you should be suspicious of functions that get called that don't seem to return anything. Can they really never fail? Note that there are linters which will warn you if you are ignoring errors (google errcheck, I don't have the URL handy). Yes there's a lot of error checking code in Go, but that's a good thing. It's explicit, and it makes you actually think about the error case. My Go programs are WAY more robust than my programs from other languages.
  - oelmekki 12y ago
    Forcing you to think about your errors is a good point, there's nothing more painful than discovering that an exception is thrown on production. I still feel it's getting in the way of the "Go allows you to be more productive" stance, though. Also, it makes it very dangerous for people not rigorous enough that will not take enough care of their errors. Granted, "it allows bad developers to do bad things" should not be an argument, but I wouldn't be surprised we hear in a few years of big fails that will be imputed to go error handling (with headlines like "Foo.com tragic fail was due to go forgetful position on handling errors").
    - NateDad 12y ago
      Go is not intended to be a fast and loose "bang it out in an afternoon" language. If you're comfortable with the language, then you can be really productive in it, but that includes error handling. You have to handle errors, that's like 50% of programming. I really doubt you'll see headlines like that. Why would you not see the same thing for code that doesn't handle exceptions in other languages? They're far more invisible than Go's errors, which are right there in the method signature.
      - oelmekki 12y ago