6 ms·

I've only just started using Go (coming from Python), and I find the existing error pattern cumbersome. It often gets in the way of understanding the function a

• gigatexal 7y ago
  Once you get used to it it’s not that bad. Editors make a macro of it so you hardly ever type it out.
  • erik_seaberg 7y ago
    Generating boilerplate is easier than reading it over and over. We need an IDE than can at least hide it and focus on the 1/4 of the lines that do something.
  • convolvatron 7y ago
    its a bit of a drag. one niggling thing is that if, should it return a zero value along with the nil, means you have to be explicit about which zero value you are using..so refactoring function return types involves touching each of these. not the end of the world, just sad. i do wish there were a type-unified zero value, or that "" and 0 were the same as nil, or some other solution here
    • gigatexal 7y ago
      Yeah I have a function like this: return a *struct, err where a nil struct could be the result of a empty result from the database query that was just run or an error if the query had an error. And then the logic of that function is if a job was returned quit early (I’m preventing two things from happening on the DB side). But then there’s an annoying dance of checking if the job is nil and the error is nil that’s the happy path... you can see how this makes the just if the check err is nil usual path welcome
• eweise 7y ago
  I like how Kotlin and Scala just let the errors bubble up to a level that cares. The code looks very clean and its clear where the error handling is.
  • dkarl 7y ago
    I really like this as well for most applications. You code the happy path and the errors that are part of the product behavior, error handling code is located where it makes sense, and unhandled exceptions get lumped into a catch-all error, such as 500 for an HTTP request. "finally" blocks take care of resources. It really hits a sweet spot for stability and honesty for applications like web services. I get that Go is targeting a systems niche where error handling is more sensitive. I think there will be fewer complaints about Go's error handling when people get a better sense for when to use it.
• marcrosoft 7y ago
  > all I see error handling do is just print the error and then return. Yeah, that is a problem. At least they had to manually type it out and (maybe) think about how to handle the error during that time. To streamline this is to further exacerbate the issue. They will do a try/catch try/defer `log.Println`. With Python try/catch allows for ultimate laziness. It allows for 1,000 line try/catch blocks that can hide/capture errors that bubble up from anywhere. Of course this is bad development but it's possible. Currently with Go it is impossible to forget about error handling. You have to consciously make a choice on what to do with it. Even if that choice is to log/print it out.
  • lgunsch 7y ago
    I once code-reviewed a serious bug-fix, in Python, causing leaking threads to crash a server. The bug turned out to be a bare try-except hiding a function call with a missing argument; 2 args passed instead of 3. Not exactly a syntax error, but pretty close.
  • dec0dedab0de 7y ago
    Many times I've had to say NO DONT DO THAT! to people writing giant try/except blocks in Python. Usually the answer is to wait for an actual exception and if it's not something you could actually anticipate, then write a tiny try block that just handles the exception. The whole point being that I want it to fail if there is an unknown exception. Which in Go, you wont fail at runtime if you are just printing errors as a habit( I think, I have not done much with go). That said, a lot of times it makes sense to return errors, and perhaps there in lies the difference between an exception and an error.
    • superbaconman 7y ago
      Massive try catch statements introduce excessive indentation, and moves the handling logic away from what's being handled. It's hard to believe that this would be common practice among anyone with a few years under the belt.
  • msbarnett 7y ago
    > Currently with Go it is impossible to forget about error handling. You’re describing some other language that forces you to deal with errors, like Haskell or Rust. A bare io.WriteString(w, “ok”) will happily compile despite returning a completely unhandled error.
• slx26 7y ago
  yeah, I kinda agree. at least in Ruby, besides the errors bubbling up, if you had to handle the error manually, you could use the truthiness of the language to write just: do_something if err I've read the other proposals, and in fact one of them (catch) is similar to what I do when I'm coding just for myself: value, err := os.Open(filename) exit_on_error(err) where the code for exit_on_error is simply something like: if err != nil { fmt.Println("Something went wrong!") os.Exit(1) } you could make it a bit more robust: value, err := os.Open(filename) handle_error(err, ERROR_FILE_OPEN) where ERROR_FILE_OPEN could be a simple constant, and in the method we have a switch with constants and messages. not a zero cost abstraction, but if you have to handle an error, it probably wasn't a cheap operation either, so the extra call won't be an issue
  • basic6 7y ago
    Go's opinionated, three line if is part of the problem. A single line if or ternary operator would reduce the line noise.
    • __david__ 7y ago
      Yeah, it's quite common in C to just do: if (error) return error; It's the same style as go, but so much more compact. If `go fmt` were to render the error boilerplate as if err { return err } …instead of the three line boilerplate it insists on, then it would go a long way. That said, I still support `try()`. It looks good to me, especially coming from Rust.
• deleted 7y ago
  [deleted]
• NelsonMinar 7y ago
  Language support for exceptions are the better way.
  • marcrosoft 7y ago
    Go is successful and popular because it is different from other languages. Most languages have exceptions and from a Go developer's point of view they are terrible.
    • apta 7y ago
      This is a non-argument really. Someone can easily say that so many things from a non-golang developer's point of view about golang are badly designed.
      • AnimalMuppet 7y ago
        Yes and no. "Go users like it" does not imply "therefore it's good", just as "Non-go users don't like it" does not imply "therefore it's bad". But "Go users like it" does imply "therefore it's not too badly mismatched to what go users are trying to do with it". Likewise, "Non-go users don't like it" implies "therefore it probably isn't a perfect fit for what non-go users are trying to do".
• ramenmeal 7y ago
  What I worry is that this problem is overhyped from new go coders (or people who took a look at go and that's it). The explicit error handling blends into the background so fast. It's never been an issue for me while developing in the past 4 years on go based systems.
  • mav3rick 7y ago
    Rust provides really good syntactic sugar that doesn't compromise on catching errors. I get Go is inspired by C, but sometimes it seems too stringent on avoiding any and everything that may make life easier for readers and programmers.
  • crimsonalucard 7y ago
    You're use to using a hammer on a screw. It's never been an issue for you for four years. It's still a big issue overall.
    • xmprt 7y ago
      You're exactly the problem the commenter is talking about. I got used to it within a month and while I would appreciate better error handling (if that even exists), I don't think the solution should be rushed and I don't think the way Java handles it is right.
      • crimsonalucard 7y ago
        I agree, but leaving it because people are used to it is not the right solution imo.
  • KirinDave 7y ago
    This is the real danger of the pattern, isn't it? It fades into the background, lulling your eyes into skipping over what's potentially a major source of bugs.
    • tylerFowler 7y ago
• dkarl 7y ago
  My experience reading and modifying Go applications has been similar. It often feels like at some point the person writing the code experienced error handling fatigue and all the error cases started blurring together. Every possibility gets explicitly handled, which is impressive, but important common cases that should be a carefully designed part of the system get the same perfunctory treatment as the weird edge cases. Go systems are the only systems I've worked with where silent failures are the most common kind of bug. "But it isn't a silent error; it's in the log and triggered an alert!" Yes, but our customers don't get our alerts. They just get 200s that they don't trust anymore. It makes me think Go's comprehensive error handling can be compared to the performance of C. If you need it, it's great; if you don't need it, the effort you invest in it will detract from something you do need.
• ernst_klim 7y ago
  IMHO the worst part of Go errors is that they are strings, so if you propagate them, you can't do anything but print them. You can't handle them properly, since you can't match them in a robust way. Just compare how good the error handling is in OCaml: http://keleshev.com/composable-error-handling-in-ocaml http://keleshev.com/composable-error-handling-in-ocaml
  • alphabettsy 7y ago
    Huh? They’re not strings. They’re an interface and you can create your own error type that implements the error interface, one of the requirements being that it has a string output available.
    • ernst_klim 7y ago
      >They’re not strings. They are strings. They are implementation of interface with a single `to_string` method, after you got `error`, you can't say (you could use switch on type, but you should guess which type could it be), so basically you have an opaque object with a single `to_string` method, which is equivalent to string. I can't fancy a more error prone way than that which Go choose. How you match the errors, you match strings? You match types? You don't even know what types could there be, since all what the type system says is that function returns error.