4 ms·

I've been using Go for a while now. The biggest headache is error handling. I don't care what the "experts" say, having exception handling is so, so, so much cl

I've been using Go for a while now. The biggest headache is error handling. I don't care what the "experts" say, having exception handling is so, so, so much cleaner in terms of error handling. Checking for err is simply bad, and trickling errors back up the call stack is one of the dumbest experiences in programming I've endured in multi-decades. If they are willing to add generics, they should add exception handling as well.

BytesAndGears 2y ago
Maybe go just isn’t for you? It really doesn’t need every feature of other languages. The error handling is ideal for me, better than any other language. You are always explicit, with every function call, about “what could happen if this fails?” Maybe passing it up the stack is the best way to handle it, but also maybe it’s better to handle it somewhere in the middle. The thing that always happens with exceptions in API projects I’ve worked on, is that exceptions can come from any level of the stack, then by default it skips everything in the middle, and the controller has default handlers for what to do in case of an exception. If there are exceptions you didn’t know existed because of some library or just complex code with dozens of possible exceptions? They still end up being handled in your controller. You need to know exactly what exceptions could happen at every level of the stack, and how to handle it, otherwise everything just short circuits. With the go errors, you only need to know “did this function call work? If not, then what?”
- hedora 2y ago
  Exceptions are a terrible idea. However, I strongly prefer rust error handling to Go. go: (res, err) := foo() if err != nil return err (res, err) := bar(res) if err != … Equivalent rust: let res = bar(foo)?)?; I think go should add the ? sigil or something equivalently terse. Ignoring all the extra keystrokes, I write “if err == nil” about 1% of the time, and then spend 30 minutes debugging it. That typo is not possible in idiomatic rust.
  - qaq 2y ago
    99% of people who never written go will know what the go version does
    - wavemode 2y ago
      Then... look it up? If someone saw "go funcName()" for the first time, would they know how it worked without looking it up?
      - qaq 2y ago
        Prob not but I would still argue go is way easier to read than Rust for someone who does not know either.
    - cowl 2y ago
      and 99% of the people will learn the ? shortcut in fraction second. it's just like every other operator ffs. are you dumbfounded everytime you see the channel operators (->) ? noone takes a second thought to them after the first couple of seconds when they encounter them the first time.
  - searealist 2y ago
    equivalent exceptions: let res = bar(foo()); (I think you meant: let res = bar(foo()?)?;
  - johnisgood 2y ago
    I don't want ")?)?;" in Go. I prefer readable syntax rather than symbol soup. In Rust, there are cases where I have seen at least 8 consecutive symbols. Not a fan of that.
  - wwweston 2y ago
    > Exceptions are a terrible idea. I hear people say this frequently, but don't ever hear people actually state the case. My experience is that particularly for web back-end exceptions have been incredibly useful, but I'm interested in the counter view.
  - 2y ago
bmurphy1976 2y ago
To each their own. I'm not going to claim to be an expert, but as somebody who's been coding since the 80s it was a breath of fresh air to see Go do what I wanted languages to do all long instead of ramming exceptions down my throat. I have problems with Go (examples: slice behavior and nil type interfaces) but error handling is not one of them.
- CharlieDigital 2y ago
  What challenge did you run into with exception handling? I'm curious because I've never felt it being onerous nor felt like there was much friction. Perhaps because I've primarily built web applications and web APIs, it's very common to simply let the exception bubble up to global middleware and handle it at a single point (log, wrap/transform). Then most of the code doesn't really care about exceptions. The only case where I might add explicit exception handling probably falls into a handful of use cases when there is a desire to a) retry, b) log some local data at the site of failure, c) perform earlier transform before rethrowing up, d) some cleanup, e) discard/ignore it because the exception doesn't matter.
  - ratorx 2y ago
    In Go, b) is really common. Most of my code will annotate a lower error with the context of the operation that was happening. You’ll ideally see errors at the top level like: “failed to process item ‘foo’: unable to open user database at ‘/some/path’: file does not exist” as an example. Here, the lowest level IO error (which could be quite unhelpful, because at best it can tell you the name of the file, but not WHY it’s being opened) is wrapped with the exact type of the file being opened (a user database) and why the database is being opened (some part of processing ‘foo’, could even generate better error message here). Although this is a bit of work (but in the grand scheme of things, not that much), it generates much better debugging info than a stack trace in a lot of situations, especially for non-transient errors because you can annotate things with method arguments. I think the common complaint of ‘if err != nil { return err }’ is generally not the case because well-written Go will usually prepend context to why the operation was being performed.
codr7 2y ago
Agreed, every time I jump back into Go I'm at first relieved at how nimble it feels; but it never takes long to remember what a pita error handling is or the kludges you need to write to do basic collection transformation pipelines (compared to Java/Streams, C#/LINQ, C++/std etc).
- throwaway2037 2y ago
  > or the kludges you need to write to do basic collection transformation pipelines (compared to Java/Streams, C#/LINQ, C++/std etc). Why hasn't anyone written a good open source for this problem, now that Go has generics?
  - codr7 2y ago
    Don't know, every time I try to do anything beyond trivial using Go generics I run into some kind of issue. They haven't been around that long, it takes time for ideas to mature.
    - throwaway2037 2y ago
      > anything beyond trivial using Go generics This is the first complaint that I have heard about Go generics on this board. I believe you. Can you share a specific example? It might spur some interesting discussion.
      - codr7 2y ago
        Haven't written much Go the last year and a half... Mostly novel limitations that I'm not used to from C++. Instantiating generic parameter types is one thing I couldn't figure out at some point, but that's pretty much useless in C# and impossible in Java if I remember correctly. I recognize the frustration from following implementations in both Java and C# though, it takes a while for generics to settle, each implementation has its own quirks.
  - metaltyphoon 2y ago
    It seems like the std library has slowly been adding generic iterators methods. Maybe one day?
rollulus 2y ago
I guess I won’t be adding new information to what your “experts” said as well, but hey. I love Go’s error handling. Syntactic sugar like in Rust could’ve made things a bit nicer to they eye, but apart from that: being forced to think about each error path leads in my view to better code. Compared to a fat try/catch and fingers crossed that all goes well in it.

BytesAndGears 2y ago

Maybe go just isn’t for you? It really doesn’t need every feature of other languages. The error handling is ideal for me, better than any other language. You are always explicit, with every function call, about “what could happen if this fails?” Maybe passing it up the stack is the best way to handle it, but also maybe it’s better to handle it somewhere in the middle. The thing that always happens with exceptions in API projects I’ve worked on, is that exceptions can come from any level of the stack, then by default it skips everything in the middle, and the controller has default handlers for what to do in case of an exception. If there are exceptions you didn’t know existed because of some library or just complex code with dozens of possible exceptions? They still end up being handled in your controller. You need to know exactly what exceptions could happen at every level of the stack, and how to handle it, otherwise everything just short circuits. With the go errors, you only need to know “did this function call work? If not, then what?”

hedora 2y ago
Exceptions are a terrible idea. However, I strongly prefer rust error handling to Go. go: (res, err) := foo() if err != nil return err (res, err) := bar(res) if err != … Equivalent rust: let res = bar(foo)?)?; I think go should add the ? sigil or something equivalently terse. Ignoring all the extra keystrokes, I write “if err == nil” about 1% of the time, and then spend 30 minutes debugging it. That typo is not possible in idiomatic rust.
- qaq 2y ago
  99% of people who never written go will know what the go version does
  - wavemode 2y ago
    Then... look it up? If someone saw "go funcName()" for the first time, would they know how it worked without looking it up?
    - qaq 2y ago
      Prob not but I would still argue go is way easier to read than Rust for someone who does not know either.
  - cowl 2y ago
    and 99% of the people will learn the ? shortcut in fraction second. it's just like every other operator ffs. are you dumbfounded everytime you see the channel operators (->) ? noone takes a second thought to them after the first couple of seconds when they encounter them the first time.
- searealist 2y ago
  equivalent exceptions: let res = bar(foo()); (I think you meant: let res = bar(foo()?)?;
- johnisgood 2y ago
  I don't want ")?)?;" in Go. I prefer readable syntax rather than symbol soup. In Rust, there are cases where I have seen at least 8 consecutive symbols. Not a fan of that.
- wwweston 2y ago
  > Exceptions are a terrible idea. I hear people say this frequently, but don't ever hear people actually state the case. My experience is that particularly for web back-end exceptions have been incredibly useful, but I'm interested in the counter view.
- 2y ago

bmurphy1976 2y ago

To each their own. I'm not going to claim to be an expert, but as somebody who's been coding since the 80s it was a breath of fresh air to see Go do what I wanted languages to do all long instead of ramming exceptions down my throat. I have problems with Go (examples: slice behavior and nil type interfaces) but error handling is not one of them.

CharlieDigital 2y ago
What challenge did you run into with exception handling? I'm curious because I've never felt it being onerous nor felt like there was much friction. Perhaps because I've primarily built web applications and web APIs, it's very common to simply let the exception bubble up to global middleware and handle it at a single point (log, wrap/transform). Then most of the code doesn't really care about exceptions. The only case where I might add explicit exception handling probably falls into a handful of use cases when there is a desire to a) retry, b) log some local data at the site of failure, c) perform earlier transform before rethrowing up, d) some cleanup, e) discard/ignore it because the exception doesn't matter.
- ratorx 2y ago
  In Go, b) is really common. Most of my code will annotate a lower error with the context of the operation that was happening. You’ll ideally see errors at the top level like: “failed to process item ‘foo’: unable to open user database at ‘/some/path’: file does not exist” as an example. Here, the lowest level IO error (which could be quite unhelpful, because at best it can tell you the name of the file, but not WHY it’s being opened) is wrapped with the exact type of the file being opened (a user database) and why the database is being opened (some part of processing ‘foo’, could even generate better error message here). Although this is a bit of work (but in the grand scheme of things, not that much), it generates much better debugging info than a stack trace in a lot of situations, especially for non-transient errors because you can annotate things with method arguments. I think the common complaint of ‘if err != nil { return err }’ is generally not the case because well-written Go will usually prepend context to why the operation was being performed.

codr7 2y ago

Agreed, every time I jump back into Go I'm at first relieved at how nimble it feels; but it never takes long to remember what a pita error handling is or the kludges you need to write to do basic collection transformation pipelines (compared to Java/Streams, C#/LINQ, C++/std etc).

throwaway2037 2y ago
> or the kludges you need to write to do basic collection transformation pipelines (compared to Java/Streams, C#/LINQ, C++/std etc). Why hasn't anyone written a good open source for this problem, now that Go has generics?
- codr7 2y ago
  Don't know, every time I try to do anything beyond trivial using Go generics I run into some kind of issue. They haven't been around that long, it takes time for ideas to mature.
  - throwaway2037 2y ago
    > anything beyond trivial using Go generics This is the first complaint that I have heard about Go generics on this board. I believe you. Can you share a specific example? It might spur some interesting discussion.
    - codr7 2y ago
      Haven't written much Go the last year and a half... Mostly novel limitations that I'm not used to from C++. Instantiating generic parameter types is one thing I couldn't figure out at some point, but that's pretty much useless in C# and impossible in Java if I remember correctly. I recognize the frustration from following implementations in both Java and C# though, it takes a while for generics to settle, each implementation has its own quirks.
- metaltyphoon 2y ago
  It seems like the std library has slowly been adding generic iterators methods. Maybe one day?

rollulus 2y ago

I guess I won’t be adding new information to what your “experts” said as well, but hey. I love Go’s error handling. Syntactic sugar like in Rust could’ve made things a bit nicer to they eye, but apart from that: being forced to think about each error path leads in my view to better code. Compared to a fat try/catch and fingers crossed that all goes well in it.