5 ms·

Go's error handling is explicit which enforces the need to handle whereas other languages leave it to the developer. More like here's the mess take care of it v

by conqrr 3y ago

Go's error handling is explicit which enforces the need to handle whereas other languages leave it to the developer. More like here's the mess take care of it vs everything looks clean but its really swept all under the rug and can bite you later. With growing dependencies and complexity increasing everyday, I'd rather think of it sooner than later.

geraneum 3y ago
About that: res, _ := some_func(…)
- iamcalledrob 3y ago
  Sure, you can do that just as much as you can do "try! some_func()" in other languages. But it's obvious that you're doing something naughty when you do.
  - geraneum 3y ago
    You’re right. But that’s my point. You can “ignore” the error and Go doesn’t force you to do anything that about it. I’ve seen this in production code. Also I’ve seen people just checking the null-ness of the return value, ignoring the error. And that brings me to my point, which is, it’s all about good programming practices, whether it’s Python or Go. edit: combating the overzealous auto-correct
iamcalledrob 3y ago
Agreed. Go forces you to think about failure just as much as success, and I find that fantastic for building robust software. Errors happen, so you're forced to do something when they do. Errors aren't exceptional. But more importantly to me, Go forces you to think about what a caller to your function might want to know about what went wrong. Errors in modern Go are for communication, not an explosion of "something bad happened, abort!" A long time ago, errors in Go were very basic -- essentially just strings 99% of the time, and I think that's where some of the hate comes from. In the early days, I think it was deserved. But nowadays, with the Go errors package (error chaining), errors are extremely powerful. Good libraries will often return an error structure that provides more context than a stack trace would, e.g. os.LinkError: https://pkg.go.dev/os#LinkError https://pkg.go.dev/os#LinkError tl;dr if you're writing "if err != nil { return err }", you're holding it wrong.
- dragonwriter 3y ago
  > Go forces you to think about failure just as much as success Except, it doesn’t. Forcing you to at least write boilerplate code for failures might be a nudge to think about them for some people, but it absolutely is not “forcing” you to think about it, and you can absolutely defer it with boilerplate while concentrating on the success path and never actually return to it.
thatswrong0 3y ago
It's explicit, but it doesn't actually enforce the need to handle it. We've had this crop up in our code base before in accidental sneaky ways, esp. when it comes to named returns and just the sheer quantity of if err != nil checks. For example: err := doSomething() if err != nil { return nil, err } err = doSomethingElse() if err != nil { return nil, err } // Oops unhandled err = doSomethingElseEntirely() // A bunch of other stuff.. return nil, nil Would much prefer "Either" with pattern matching, or something else that actually forces you to do something.

by conqrr 3y ago

geraneum 3y ago

About that: res, _ := some_func(…)

iamcalledrob 3y ago
Sure, you can do that just as much as you can do "try! some_func()" in other languages. But it's obvious that you're doing something naughty when you do.
- geraneum 3y ago
  You’re right. But that’s my point. You can “ignore” the error and Go doesn’t force you to do anything that about it. I’ve seen this in production code. Also I’ve seen people just checking the null-ness of the return value, ignoring the error. And that brings me to my point, which is, it’s all about good programming practices, whether it’s Python or Go. edit: combating the overzealous auto-correct

iamcalledrob 3y ago

Agreed. Go forces you to think about failure just as much as success, and I find that fantastic for building robust software. Errors happen, so you're forced to do something when they do. Errors aren't exceptional. But more importantly to me, Go forces you to think about what a caller to your function might want to know about what went wrong. Errors in modern Go are for communication, not an explosion of "something bad happened, abort!" A long time ago, errors in Go were very basic -- essentially just strings 99% of the time, and I think that's where some of the hate comes from. In the early days, I think it was deserved. But nowadays, with the Go errors package (error chaining), errors are extremely powerful. Good libraries will often return an error structure that provides more context than a stack trace would, e.g. os.LinkError: https://pkg.go.dev/os#LinkError https://pkg.go.dev/os#LinkError tl;dr if you're writing "if err != nil { return err }", you're holding it wrong.

dragonwriter 3y ago
> Go forces you to think about failure just as much as success Except, it doesn’t. Forcing you to at least write boilerplate code for failures might be a nudge to think about them for some people, but it absolutely is not “forcing” you to think about it, and you can absolutely defer it with boilerplate while concentrating on the success path and never actually return to it.

thatswrong0 3y ago

It's explicit, but it doesn't actually enforce the need to handle it. We've had this crop up in our code base before in accidental sneaky ways, esp. when it comes to named returns and just the sheer quantity of if err != nil checks. For example: err := doSomething() if err != nil { return nil, err } err = doSomethingElse() if err != nil { return nil, err } // Oops unhandled err = doSomethingElseEntirely() // A bunch of other stuff.. return nil, nil Would much prefer "Either" with pattern matching, or something else that actually forces you to do something.