5 ms·

Why Go's Error Handling Is Awesome

25 points by chautumn 2y ago

bvrmn 2y ago
> No hidden control-flows It's so much fun to `return err` through every layer. Explicit no-op attached to every call, yeah! > No unexpected uncaught exception logs blowing up your terminal (aside from actual program crashes via panics) A great opportunity to search a code base for logging messages and reconstruct traces by hand. A real true craft! > full-control of errors in your code as values you can handle, return, and do anything you want with Yes, it's a real engineering marvel. Exceptions are so bad at this, you could only catch it and, wait... > Rust, for example, has a good compromise of using option types and pattern matching to find error conditions, leveraging some nice syntactic sugar to achieve similar results. Thank you for mentioning Rust, I guess. It's very saddle not to include `try` on the table.
- InsideOutSanta 2y ago
  "No unexpected uncaught exception logs blowing up your terminal" Yeah, this one jumped out to me, too. I like exceptions in my logs when something unexpected happens.
  - chrsig 2y ago
    i don't like unexpected things happening. they cause me to panic. i can expect errors.
fdsfdsaafdsads 2y ago
[dead]
CharlieDigital 2y ago
Is there some actual proof that Go code is less prone to runtime errors or more maintainable or easier to debug because of this? Surely, if Go's method of error handling is superior to every other programming language, there must be some meaningful statistical side effects that can be observed to prove it right? Lower rate of runtime errors, faster time to debug errors, etc. Someone out there in academia must have been able to actually measure this effect if it exists? If not, can team Go stop going on and on about how superior their excess keystrokes are?
- throwaway519 2y ago
  Prive has a specific meaning. Are you seeking proveble code like box logic and Haskell? Or do you seek someone to, rather than prove one screwdriver is less error prone than another, to demonstrate it is? If so, that would depend on context of screws, wood, lefthandedness. A proof in a special case is especially limited. So a demonstration. Can you demonstrate Go's method of error hanling for a specific context is superior? Yes, you can.
  - CharlieDigital 2y ago
    Prove as in statistical evidence that code and teams working with Go yield software that has lower rates of runtime defects, has faster time to debug runtime errors, has improved the productivity of developers because of its obviously superior design and philosophy of error handling, etc. These are all measurable. Productivity is measurable. Defect rates are measurable. Time to debug is measurable. If there's a peer reviewed paper, let's see it. If there's not, you should produce it and get hired by the Go team! If this is indeed the superior way of handling errors: varFoo, err := GetFoo() if err != nil { return err } and not just excess key strokes and preference of style, then there will be some statistical side effect that can be measured to prove its superiority. If you can't prove it, all you're saying is "I prefer purple because purple is obviously superior to blue! Can't you see!"...O...K.
    - deleted 2y ago
      [deleted]
  - lolinder 2y ago
    You're being pedantic, and as is often the case when people are pedantic you're also wrong [0]. Their use of the word "prove" is entirely consistent with standard definitions, and "demonstrate" is listed as a synonym for "prove". > Can you demonstrate Go's method of error hanling for a specific context is superior? Yes, you can. Then please do! Articles like this one are entirely subjective and anecdote-oriented, not evidence-based proofs (or demonstrations if you like). [0] https://www.merriam-webster.com/dictionary/prove https://www.merriam-webster.com/dictionary/prove
hackingonempty 2y ago
Golang sends you to null checking hell. https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ https://philipnilsson.github.io/Badness10k/escaping-hell-wit...
lolinder 2y ago
> However, in other languages, it may not be clear that your code is not handling a potential exception in a try catch code block, being completely opaque about handling your control flow. In other words, Go's error handling is an even less ergonomic way to do checked exceptions than Java's checked exceptions. I'm of the opinion that Java was right all along and they just didn't have the inference tools to make it ergonomic at the time, but I'm in a tiny minority there, and most of this article could have been swapped out as a defense of checked exceptions, while the rest is a subjective defense of the syntax. And then there are the things that checked exceptions give you that Go's errors don't: * Automatic stack traces. No need to decide that the error is "actionable to developers" and remember to load a library and wrap the error, errors have stack traces. I can't emphasize this enough. * You can opt out of the line-by-line exception handling by just declaring that your function can throw. The line-by-line manual handling is only valuable in cases where your functions are very long and might throw many errors (problematic for other reasons) or if you don't have stack traces and need to piece line numbers together by hand (see above). There are other flaws in Java's implementation, but it's been very frustrating to see how many of the new languages just reinvented Java's checked exceptions but worse instead of iterating on them.
frou_dh 2y ago
This starts off immediately with in-group/out-group tribal mindset: > Go's infamous error handling has caught quite the attention from outsiders to the programming language, often touted as one of the language's most questionable design decisions. > Although it may seem redundant and unnecessary for those new to the language I have plenty Go experience, yet think the lack of sum-types is iffy. But I don't identify as a true-blue "gopher" so I guess I must be an outsider that just doesn't get it.
deleted 2y ago
[deleted]
kaapipo 2y ago
I'm not even sure why we are still stuck in this debate. Isn't there quite a big consensus that the best way to handle errors is to have everything return an `Either<T, Error>` and having first-class support for monadic types? Any design that doesn't actually force you to handle the error case cannot be called good in my opinion.
deleted 2y ago
[deleted]
BadBadJellyBean 2y ago
I stronlgy dislike Go's error handling. It is incredibly annoying to add if err != nil { <do stuff> } after nearly every function call and to have a error as a secondary return type. At least for me it is clunky and annoying and incredibly distracting. If there was at least some syntactic sugar around this I could probably live with it but like this I just don't like using Go.
- zeroc8 2y ago
  This works for me. if res, err := doSomething(); err == nil { return nil, err } no point in continuing with a null object anyway
- aleksiy123 2y ago
  In google c++ there are two macros which I feel make it look a lot nicer. ASSIGN_AND_RETURN(auto var, status_or); And RETURN_IF_ERROR(status); Which are just more ergonomic with the drawback of being macros.
labradore99 2y ago
[flagged]
malcolmgreaves 2y ago
Wait until the author learns about sum types. They’re only probably older than the author themselves!
jasonthorsness 2y ago
I wish they would improve the syntax for error handling with multiple return values. When your function returns something like (string, error) you need to write: return "", err each time. Then if you introduce another return value, you need to edit a ton of lines to also return a value for that one, typically just to return the default of each along with the error. Not only is that annoying, but it's prone to carelessly returning something non-default along with the error due to copy/pasting. But complaints aside, I agree with the article that Go's error handling is pretty awesome.
RGBCube 2y ago
Every time I see an article or post that thinks Go's error handling is good, I ask myself: Have these people never used anything outside of Python, C++ and $LANG where exceptions without type constraints are the norm? Go error handling is literal garbage compared to things like OCaml's Result plus anonymous unions, or Haskell and Rust's Either and Result.
xkbarkar 2y ago
strictly speaking you could use the must pattern and wrap err in there to avoid the constant if err != nil Albeit it transfers repetition from one place to another.
peterashford 2y ago
I like Go. A whole lot. I program in it every day and it's a joy. Except for the error handling. It sucks so much. I cannot believe that they chose to keep the worst feature of C. I read articles like this one and I believe that Stockholm Syndrome must really exist, after all. I would take ANY error handling system over "check every single &^%!! function call result" - result types, exceptions, whatever.

25 points by chautumn 2y ago

> No hidden control-flows It's so much fun to `return err` through every layer. Explicit no-op attached to every call, yeah! > No unexpected uncaught exception logs blowing up your terminal (aside from actual program crashes via panics) A great opportunity to search a code base for logging messages and reconstruct traces by hand. A real true craft! > full-control of errors in your code as values you can handle, return, and do anything you want with Yes, it's a real engineering marvel. Exceptions are so bad at this, you could only catch it and, wait... > Rust, for example, has a good compromise of using option types and pattern matching to find error conditions, leveraging some nice syntactic sugar to achieve similar results. Thank you for mentioning Rust, I guess. It's very saddle not to include `try` on the table.

InsideOutSanta 2y ago
"No unexpected uncaught exception logs blowing up your terminal" Yeah, this one jumped out to me, too. I like exceptions in my logs when something unexpected happens.
- chrsig 2y ago
  i don't like unexpected things happening. they cause me to panic. i can expect errors.

fdsfdsaafdsads 2y ago

[dead]

CharlieDigital 2y ago

Is there some actual proof that Go code is less prone to runtime errors or more maintainable or easier to debug because of this? Surely, if Go's method of error handling is superior to every other programming language, there must be some meaningful statistical side effects that can be observed to prove it right? Lower rate of runtime errors, faster time to debug errors, etc. Someone out there in academia must have been able to actually measure this effect if it exists? If not, can team Go stop going on and on about how superior their excess keystrokes are?

throwaway519 2y ago
Prive has a specific meaning. Are you seeking proveble code like box logic and Haskell? Or do you seek someone to, rather than prove one screwdriver is less error prone than another, to demonstrate it is? If so, that would depend on context of screws, wood, lefthandedness. A proof in a special case is especially limited. So a demonstration. Can you demonstrate Go's method of error hanling for a specific context is superior? Yes, you can.
- CharlieDigital 2y ago
  Prove as in statistical evidence that code and teams working with Go yield software that has lower rates of runtime defects, has faster time to debug runtime errors, has improved the productivity of developers because of its obviously superior design and philosophy of error handling, etc. These are all measurable. Productivity is measurable. Defect rates are measurable. Time to debug is measurable. If there's a peer reviewed paper, let's see it. If there's not, you should produce it and get hired by the Go team! If this is indeed the superior way of handling errors: varFoo, err := GetFoo() if err != nil { return err } and not just excess key strokes and preference of style, then there will be some statistical side effect that can be measured to prove its superiority. If you can't prove it, all you're saying is "I prefer purple because purple is obviously superior to blue! Can't you see!"...O...K.
  - deleted 2y ago
    [deleted]
- lolinder 2y ago
  You're being pedantic, and as is often the case when people are pedantic you're also wrong [0]. Their use of the word "prove" is entirely consistent with standard definitions, and "demonstrate" is listed as a synonym for "prove". > Can you demonstrate Go's method of error hanling for a specific context is superior? Yes, you can. Then please do! Articles like this one are entirely subjective and anecdote-oriented, not evidence-based proofs (or demonstrations if you like). [0] https://www.merriam-webster.com/dictionary/prove https://www.merriam-webster.com/dictionary/prove

hackingonempty 2y ago

Golang sends you to null checking hell. https://philipnilsson.github.io/Badness10k/escaping-hell-with-monads/ https://philipnilsson.github.io/Badness10k/escaping-hell-wit...

lolinder 2y ago

> However, in other languages, it may not be clear that your code is not handling a potential exception in a try catch code block, being completely opaque about handling your control flow. In other words, Go's error handling is an even less ergonomic way to do checked exceptions than Java's checked exceptions. I'm of the opinion that Java was right all along and they just didn't have the inference tools to make it ergonomic at the time, but I'm in a tiny minority there, and most of this article could have been swapped out as a defense of checked exceptions, while the rest is a subjective defense of the syntax. And then there are the things that checked exceptions give you that Go's errors don't: * Automatic stack traces. No need to decide that the error is "actionable to developers" and remember to load a library and wrap the error, errors have stack traces. I can't emphasize this enough. * You can opt out of the line-by-line exception handling by just declaring that your function can throw. The line-by-line manual handling is only valuable in cases where your functions are very long and might throw many errors (problematic for other reasons) or if you don't have stack traces and need to piece line numbers together by hand (see above). There are other flaws in Java's implementation, but it's been very frustrating to see how many of the new languages just reinvented Java's checked exceptions but worse instead of iterating on them.

frou_dh 2y ago

This starts off immediately with in-group/out-group tribal mindset: > Go's infamous error handling has caught quite the attention from outsiders to the programming language, often touted as one of the language's most questionable design decisions. > Although it may seem redundant and unnecessary for those new to the language I have plenty Go experience, yet think the lack of sum-types is iffy. But I don't identify as a true-blue "gopher" so I guess I must be an outsider that just doesn't get it.

deleted 2y ago

[deleted]

kaapipo 2y ago

I'm not even sure why we are still stuck in this debate. Isn't there quite a big consensus that the best way to handle errors is to have everything return an `Either<T, Error>` and having first-class support for monadic types? Any design that doesn't actually force you to handle the error case cannot be called good in my opinion.

deleted 2y ago

[deleted]

BadBadJellyBean 2y ago

I stronlgy dislike Go's error handling. It is incredibly annoying to add if err != nil { <do stuff> } after nearly every function call and to have a error as a secondary return type. At least for me it is clunky and annoying and incredibly distracting. If there was at least some syntactic sugar around this I could probably live with it but like this I just don't like using Go.

zeroc8 2y ago
This works for me. if res, err := doSomething(); err == nil { return nil, err } no point in continuing with a null object anyway
aleksiy123 2y ago
In google c++ there are two macros which I feel make it look a lot nicer. ASSIGN_AND_RETURN(auto var, status_or); And RETURN_IF_ERROR(status); Which are just more ergonomic with the drawback of being macros.

labradore99 2y ago

[flagged]

malcolmgreaves 2y ago

Wait until the author learns about sum types. They’re only probably older than the author themselves!

jasonthorsness 2y ago

I wish they would improve the syntax for error handling with multiple return values. When your function returns something like (string, error) you need to write: return "", err each time. Then if you introduce another return value, you need to edit a ton of lines to also return a value for that one, typically just to return the default of each along with the error. Not only is that annoying, but it's prone to carelessly returning something non-default along with the error due to copy/pasting. But complaints aside, I agree with the article that Go's error handling is pretty awesome.

RGBCube 2y ago

Every time I see an article or post that thinks Go's error handling is good, I ask myself: Have these people never used anything outside of Python, C++ and $LANG where exceptions without type constraints are the norm? Go error handling is literal garbage compared to things like OCaml's Result plus anonymous unions, or Haskell and Rust's Either and Result.

xkbarkar 2y ago

strictly speaking you could use the must pattern and wrap err in there to avoid the constant if err != nil Albeit it transfers repetition from one place to another.

peterashford 2y ago

I like Go. A whole lot. I program in it every day and it's a joy. Except for the error handling. It sucks so much. I cannot believe that they chose to keep the worst feature of C. I read articles like this one and I believe that Stockholm Syndrome must really exist, after all. I would take ANY error handling system over "check every single &^%!! function call result" - result types, exceptions, whatever.