Here is the code fragment:
The debugger first stops at line 64. Then I press F10 to "step over" and then it jumps to line 75. There is a breakpoint at line 74, but it simply ignores that.
wsconn is a simple struct with a handleCall method defined on it:
/*
This private method simply selects and calls the right handler for
a given "call", sent by the client.
*/
func (wsconn InternalWsConn) handleCall(method string) error {
handler, ok := api.CallHandlers[method]
if !ok {
// Read arguments, even if we cannot find the method.
// The client sends the arguments unconditionally anyway.
_, _, err := wsutil.ReadClientData(wsconn.conn)
if err != nil {
return err
}
return fmt.Errorf("call error: invalid method: %v", method)
}
return handler(wsconn)
}
If I place a breakpoint inside the handleCall method, then the debugger stops there. It just refuses to stop on line 74. So I can debug the code if I want to.
But I'm a bit frightened, because it seems that vs code allows to put breakpoints at places and then it does not work. I can possibly face the same problem again and again, and spend hours with this before I realize that a problem is not where I'm looking for it.
So the real question is this: why it is happening? Is it a problem with vscode? Or is it a problem with go itself? (Tested with go1.19.1 linux/amd64.) How can I avoid this? If I can't avoid, then is there a way to at least predict the places where I should not place breakpoints, because they are probably not going to work?
