4 ms·

> 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 hav

> 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
      > Go is not intended to be a fast and loose "bang it out in an afternoon" language I was hoping for nothing that extreme :) But this is something I have to consider. I'm cto, in my company, and the "how much time to build that feature" is something that has a very real importance when we decide what to implement. Ruby got us into thinking of features as a weekly thing. I can justify to spend most of the week doing in go what I would have done in a day with ruby if it allows to do things we could not do in ruby or allows to scale up (and I've already done so for resource heavy background tasks that could be parallelized, actually). Doing it in C probably would have taken more than a week. That's the extent of what I mean by "productivity" in go. > You have to handle errors, that's like 50% of programming Well, that's the problem. That's 50% (probably less actually, but nevermind) of go programming. The hard reality is that I care for only 10% of those errors. If a file was supposed to be transferred to a third party server and this one is down, certainly, I want to handle error, inform user about the situation and ask her to come back later. But if something is supposed to work 100% of the time, I don't want to have to spend time writing code that would probably just never be executed just in case an unforeseen circumstance happens. I want an exception (with some exception handling system behind that notifying me about the exception, of course, which would be a one time configuration for the whole kind of those errors) and a generic error message for the user. That's a productivity thing too. And indeed, most of my error handling in go are : if err != nil { panic( err ) }
      - NateDad 12y ago
        If something is supposed to work 100% of the time, it won't have an error return value. Otherwise there's a nonzero chance it'll fail. The time you spend writing a simple "network configuration file must exist" is way less than you'd spend trying to read a stack trace when your application crashes with "filenotfound: foo.json". If Go is 1/5th as productive as Ruby to produce the same feature, either you're very new to go and very experienced with ruby, or you're doing something drastically wrong. Obviously, experience makes a difference, but Go has a very short learning curve, so you should able to get productive relatively quickly. I honestly don't understand how you can only care about 10% of errors. You have to think about the error case, otherwise your application is going to be a crashy, data lossy mess and no will trust it.

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
    > Go is not intended to be a fast and loose "bang it out in an afternoon" language I was hoping for nothing that extreme :) But this is something I have to consider. I'm cto, in my company, and the "how much time to build that feature" is something that has a very real importance when we decide what to implement. Ruby got us into thinking of features as a weekly thing. I can justify to spend most of the week doing in go what I would have done in a day with ruby if it allows to do things we could not do in ruby or allows to scale up (and I've already done so for resource heavy background tasks that could be parallelized, actually). Doing it in C probably would have taken more than a week. That's the extent of what I mean by "productivity" in go. > You have to handle errors, that's like 50% of programming Well, that's the problem. That's 50% (probably less actually, but nevermind) of go programming. The hard reality is that I care for only 10% of those errors. If a file was supposed to be transferred to a third party server and this one is down, certainly, I want to handle error, inform user about the situation and ask her to come back later. But if something is supposed to work 100% of the time, I don't want to have to spend time writing code that would probably just never be executed just in case an unforeseen circumstance happens. I want an exception (with some exception handling system behind that notifying me about the exception, of course, which would be a one time configuration for the whole kind of those errors) and a generic error message for the user. That's a productivity thing too. And indeed, most of my error handling in go are : if err != nil { panic( err ) }
    - NateDad 12y ago
      If something is supposed to work 100% of the time, it won't have an error return value. Otherwise there's a nonzero chance it'll fail. The time you spend writing a simple "network configuration file must exist" is way less than you'd spend trying to read a stack trace when your application crashes with "filenotfound: foo.json". If Go is 1/5th as productive as Ruby to produce the same feature, either you're very new to go and very experienced with ruby, or you're doing something drastically wrong. Obviously, experience makes a difference, but Go has a very short learning curve, so you should able to get productive relatively quickly. I honestly don't understand how you can only care about 10% of errors. You have to think about the error case, otherwise your application is going to be a crashy, data lossy mess and no will trust it.