4 ms·

yeah go/rust error handling is great. Much better than exceptions which make the code hard to read since you can't easily predict where is the flow going to jum

• tokenizerrr 11y ago
  My problem with Go (and I love the language a lot) is that a lot of my error handling is "stop execution in the function and bubble the error up", which results in my code being littered with if err != nil { return err }, which is a bit annoying. If I'm doing something wrong here I'd love to know it.
  • vardump 11y ago
    You're not doing anything wrong. And I think it's better that way, to have the error possibilities visible and very understandable. All the context you need to see the error handling is in front of you, not hidden in 25 different files. That's a blessing.
  • cjslep 11y ago
    The only other idea (and it isn't a very good one) I've seen is to put the error as a parameter and let the called function early return if given a non-nil error: http://play.golang.org/p/bRdFWBZp5r http://play.golang.org/p/bRdFWBZp5r
  • mtrn 11y ago
    Sometimes other techniques are more useful. - you can collect errors in a function and return them once or provide an extra method, like http://golang.org/pkg/bufio/#Scanner.Err http://golang.org/pkg/bufio/#Scanner.Err - you can type switch on the error; maybe there are errors that you can recover/retry locally, such as connection errors, or general io failures - so you do not need to pass back all errors to the caller More on errors: https://blog.golang.org/errors-are-values https://blog.golang.org/errors-are-values
  • wcummings 11y ago
    This annoyed me to no end working in node.js, having to manually re-raise errors at every step is pretty tiresome and error prone (no pun intended).
    • vendakka 11y ago
      I've recently started working in node after spending some time in Go-land and the reverse applies to me. The code I'm writing is a mix of js + Go and I find that in JS I have no sense for what can go wrong since it's not obvious to me if a method will throw an exception or not. However, with Go it forces me to think about my error path. I do find littering code with err checks can be annoying and ended up reaching a compromise. For all code that is likely to be part of an externally public package I use 'if err !=' checks. For application level code that will be internal to my application (and internal to the file I'm working in) I use a small library [1] I wrote, that uses the panic-defer-recover style talked about in the Go documents for internal error handling [2]. However, I find that in most situations I usually prefer to not use panic-defer-recover, with if checks providing more clarity. [1] https://github.com/surullabs/fault https://github.com/surullabs/fault [2] http://golang.org/doc/effective_go.html#recover http://golang.org/doc/effective_go.html#recover
  • wvenable 11y ago
    That's exactly why exceptions were invented. They aren't really as magical and hard to understand as the parent poster seems to think. In a theoretical sense, exceptions just do if err != nil { return err } on every call automatically. I feel like so many developers have been so damaged by Java's approach to exception handling that, of course, error codes seem simpler by comparison. I can't help by feel the recent push-back against exceptions is a step backwards in many situations. A whole generation of developers will have to re-learn the pain that lead to the development of exceptions in the first place.