3 ms·

I feel like a caveman typing out error handling code in go, but on the other hand (even as a beginner in Go) I _never_ run into unexpected conditions. There's t

I feel like a caveman typing out error handling code in go, but on the other hand (even as a beginner in Go) I _never_ run into unexpected conditions. There's tradeoffs of course but every time I find myself thinking about what kinds of error conditions may be happening in my Node code (where I spend most of my time), and whether I covered them all... i think I'd trade.

herval 8y ago
I keep shooting myself in the foot _the same way_, all the time - and it's incredibly easy to do so: - not knowing if "Foo" being returned is a struct or an interface, so you're not sure if you should "if foo != nil" (it could not be nil if it's a struct) - channels freezing (specially unbuffered ones). I still can't figure out how to debug those well. - (the most common of all) spawning goroutines on a for loop, and all of them closuring over the same value (instead of one per item on the loop) it's a surprising amount of sharp edges, for such a tiny language...
- gant 8y ago
  1. Get IDE support. There is no convention of adding a suffix like "Interface", and I personally am very happy with this. C# ISomething naming conventions have annoyed me quite a bit. 2. Always limit the scope of your channels. I like using unidirectional channels with structs that have more unidirectional channels. (For instance, a chan of workRequest{workData, returnChan} where return chan only receives responses for this request and is closed when no values are left) 3. I think you've been treated to well by JS closures, always hand over arguments you're going to use in the goroutine, this also allows the CG to clean up the stack of the function that started the closure goroutine.
  - herval 8y ago
    1. Naming conventions don’t solve syntax warts. Modern languages solve this as part of their null safety (eg optional monads or the ? on kotlin and swift) 2. Yes, I know how to “properly” do it. Does not eliminate human error. 3. Closures in any other language, afaik. I rarely code in Js, fyi
    - gant 8y ago
      Regarding 1, I (and seemingly everyone else writing libraries) usually return (value, error) and treat a nil value as error. We have quite a bit of old code at work that might segfault because it wasn't done like this. Most of our Kubernetes code looks something like this _, err := clientInterface.Update(object) if err != nil { if machinery_errors.IsNotFound(err) { //handle nil case } else // handle unexpected case } }
marcus_holmes 8y ago
this. I'm writing a system in Go and Vue at the moment, and while there is a certain tedium to writing "if err != nil { " for the thousandth time, I'm happy that if an error occurs somewhere it's not going to get silently passed up the stack until it pops up somewhere totally out of context.

herval 8y ago

I keep shooting myself in the foot _the same way_, all the time - and it's incredibly easy to do so: - not knowing if "Foo" being returned is a struct or an interface, so you're not sure if you should "if foo != nil" (it could not be nil if it's a struct) - channels freezing (specially unbuffered ones). I still can't figure out how to debug those well. - (the most common of all) spawning goroutines on a for loop, and all of them closuring over the same value (instead of one per item on the loop) it's a surprising amount of sharp edges, for such a tiny language...

gant 8y ago
1. Get IDE support. There is no convention of adding a suffix like "Interface", and I personally am very happy with this. C# ISomething naming conventions have annoyed me quite a bit. 2. Always limit the scope of your channels. I like using unidirectional channels with structs that have more unidirectional channels. (For instance, a chan of workRequest{workData, returnChan} where return chan only receives responses for this request and is closed when no values are left) 3. I think you've been treated to well by JS closures, always hand over arguments you're going to use in the goroutine, this also allows the CG to clean up the stack of the function that started the closure goroutine.
- herval 8y ago
  1. Naming conventions don’t solve syntax warts. Modern languages solve this as part of their null safety (eg optional monads or the ? on kotlin and swift) 2. Yes, I know how to “properly” do it. Does not eliminate human error. 3. Closures in any other language, afaik. I rarely code in Js, fyi
  - gant 8y ago
    Regarding 1, I (and seemingly everyone else writing libraries) usually return (value, error) and treat a nil value as error. We have quite a bit of old code at work that might segfault because it wasn't done like this. Most of our Kubernetes code looks something like this _, err := clientInterface.Update(object) if err != nil { if machinery_errors.IsNotFound(err) { //handle nil case } else // handle unexpected case } }

marcus_holmes 8y ago

this. I'm writing a system in Go and Vue at the moment, and while there is a certain tedium to writing "if err != nil { " for the thousandth time, I'm happy that if an error occurs somewhere it's not going to get silently passed up the stack until it pops up somewhere totally out of context.