When in Go, do as Gophers do

Post by bsaul » Sun, Dec 07, 2014, 2:51 PM UTC

webtopaz wrote: post #29

bsaul wrote: post #26

Earlier quoted context omitted.

I looked at this slide for a while and couldn't understand it. Could you explain the detail a bit ? It seems like relying on dynamic type casting over a nil variable, is that correct ? But then what would the following "if" look like ?

This is how you can make sure that a struct implements an interface. The line 'var _ scan.Writer = (*ColumnWriter)(nil)' assigns a nil pointer of the struct to a scan.Writer interface reference which would fail if ColumnWriter doesn't implement the interface. And the casting always works.

Post by NateDad » Sun, Dec 07, 2014, 3:15 PM UTC

zimbatm wrote: post #21

mratzloff wrote: post #6

Earlier quoted context omitted.

If you have only worked in languages with exceptions, it's not surprising that you would struggle with Go's C-style error handling. I've grown to prefer it, as exception handling typically boils down to "not my problem" in most code bases. Go forces you to think through each error condition, which is an unusual amount of effort for people who may not be accustomed to it.

Go's error handling works well in small programs but there's a couple of issues. One is that it quickly becomes hard to find out where errors really came from. Consider this idiomatic code: func MyFunc(input int) (output int, err error) { if output, err = someOtherFuncA(input); err != nil { return } if output, err = someOtherFuncB(output); err != nil { return } // ... } If MyFunc returns an error it's not possible to…

Post by NateDad » Sun, Dec 07, 2014, 3:20 PM UTC

StavrosK wrote: post #25

bsaul wrote: post #22

Earlier quoted context omitted.

That's a question i've often asked myself, whether having me think about error handling at almost every line of code was actually a good thing, or just plain overkill since most of time killing the top-most function ( and maybe retry it) is the only thing to do. I don't really have an answer to that. But what i know is that i find the practice of having typed exception in java plus catching the one you want to deal w…

I agree with that as well. I was just now writing a program to receive a command and perform an action, and sometimes it will receive invalid commands, or there will be some error performing the action. In these cases, I just want it to ignore the errors and resume its loop. With Python, you just wrap it in a try/catch and forget about it. With Go, I already wrote five error checks and I'm sure I haven't caught some…

    if err != nil {
        continue
    }

Post by userbinator » Sun, Dec 07, 2014, 3:24 PM UTC

myg204 wrote: post #13

sanswork wrote: post #2

I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. I'm enjoying using Go for the few small services I'm using it for but it seems that a language which has to constantly fight it's users to reinforce what it considers idiomatic has some core issues.

> I've never known a language with so much discussion on why what you are doing isn't idiomatic as Go. Python is another language where there is a lot of talk about idiomatic code ('Pythonic'). C++11 and C++14 also have a lot of idiomatic discussion since the community's trying to move to a different style with the latest enhancements. Not sure if this is a signal of core issues.

Post by StavrosK » Sun, Dec 07, 2014, 3:27 PM UTC

NateDad wrote: post #35

StavrosK wrote: post #25

Earlier quoted context omitted.

I agree with that as well. I was just now writing a program to receive a command and perform an action, and sometimes it will receive invalid commands, or there will be some error performing the action. In these cases, I just want it to ignore the errors and resume its loop. With Python, you just wrap it in a try/catch and forget about it. With Go, I already wrote five error checks and I'm sure I haven't caught some…

I don't understand. What's wrong with this in the loop? if err != nil { continue }