3 ms·

> My problem with errors in Go are that they are too easy to ignore accidentally This is a problem for values of all types, not just errors. One I'm not sure w

• hot_gril 2y ago
  It's a problem for values of all types, which is why exceptions are usually handled specially in other languages. I get that it seems impure, but everything you call has some way to fail <1% of the time that you probably want to handle very differently from any other outcome. It's sensible for a language to force you to either designate a different code path for that or let it bubble up (edit: which, to clarify, Golang does not enforce with error return types, which is what the other person dislikes about it).
  • randomdata 2y ago
    I've read a lot of code in my life. I see that exception handlers are sometimes used to carry errors, virtually always exceptions, but almost never anything else. Who is it that you are think are passing around email addresses and geocooreinates using exception handlers? But even assuming it is done sometimes, is the developer going to actually handle it? I don't know how many times I've come across "catch" blocks that are empty or something equally inappropriate. Nothing was gained. It turns out that programmers will still forget no matter how hard you try to hold their hand. I'm not sure there is any other solution than to test it, and once you get into testing, entire blocks of logic missing are going to stick out like a sore thumb. Forgetting an entire branch is not exactly a subtle bug. At that point it really doesn't matter what language constructs you do or don't have available.
    • shepherdjerred 2y ago
      > I don't know how many times I've come across "catch" blocks that are empty or something equally inappropriate. Nothing was gained. It turns out that programmers will still forget no matter how hard you try to hold their hand. You are right, but the difference is that the programmer is making the choice to ignore that error versus accidentally ignoring the error.
      • randomdata 2y ago
        There was no indication that it was an active choice. I'm speaking to where it was clearly incorrect behaviour, not where one honestly wanted to ignore the condition. I'm assuming these programmers would write out the boilerplate (perhaps even automatically by some IDE feature) and then forgot to return to it to fill in the logic. And fair enough. It would be just as easy to forget to do that as it would be to forget to handle errors in any other language. There is no silver bullet here.
        • hot_gril 2y ago
          Adding a try{...} with an empty catch{} takes a lot more effort than simply forgetting to do something with an error return value.
• shepherdjerred 2y ago
  > This is a problem for values of all types, not just errors. One I'm not sure we've figured out how to solve[1]. There are a few languages out there that force variable assignment to try and address the problem, but even then there is really nothing to say that you haven't accidentally ignored the variable assigned. The difference is that the happy case is well-tested. If you aren't handled the error-free route you probably will notice that very quickly unless you aren't testing your code, even manually. e.g. it doesn't matter if you ignore normal variable assignments because the programmer will usually catch that themselves. They will not likely catch all of the possible error assignments without some help. > To be fair, if you are able to completely leave out entire blocks of logic without anyone noticing even under the most cursory of testing, perhaps it wasn't actually needed? Forgetting entire code branches isn't exactly a subtle bug. In this case we were silently ignoring errors which caused multiple types of issues that we had to then manually track down. This is an entire class of defects that can be avoided with better tooling, either at the language level with checked exceptions, or with a linter like errcheck.
  • hot_gril 2y ago
    errcheck seems very sensible.