2 ms·

Yes, the workaround for unused things is: - comment out a line of code to check something. - compile, get an error about unused variables because a variable i

Yes, the workaround for unused things is: - comment out a line of code to check something. - compile, get an error about unused variables because a variable is unused now that the line that used it is commented out. - go back to the code and comment out that other line. - compile, get another error because there's another two variables that are now unused. - comment those lines out. - compile, get another error because an import is now considered unused. - repeat ad nauseum. - Fix the bug. - Uncomment everything you commented, and try to undo any changes you made to get around unused variables so that your code is mostly back to where it was, plus the bugfix. - Last compile to make sure everything works. -- I prefer this method: - Install a custom go compiler from https://github.com/kstenerud/go https://github.com/kstenerud/go - comment out a line of code to check something. - go test -gcflags=-warnunused - fix the bug. - uncomment the line. - go test -- This has nothing to do with the difficulty of debugging the code, or the complexity of the code you are debugging. This is about getting the compiler to stop fighting you.

blablabla123 7y ago
I must admit it's not perfect. What I usually do is add _ = unusedVar and then do the debugging stuff. Not sure why, but over time I ran into this procedure far less often but I do very pedantic error checking like return fmt.Errorf("foo(%v): %v", fn, err) and putting in checks sometimes that can return custom errors. So in my log I often end up with messages like "bar: baz: foo(/data.txt): open: file not found". Debugging usually means for me replacing return err with a more verbose return fmt.Errorf("...: %v", err) and adding mentioned checks and/or additional log messages. Either with the log package or logrus. (And possibly adding unit tests/factoring out code into separate functions.) This gives me information content like in a full Java stack trace but in one line. But YMMV, probably it also depends what kind of software one writes.

blablabla123 7y ago

I must admit it's not perfect. What I usually do is add _ = unusedVar and then do the debugging stuff. Not sure why, but over time I ran into this procedure far less often but I do very pedantic error checking like return fmt.Errorf("foo(%v): %v", fn, err) and putting in checks sometimes that can return custom errors. So in my log I often end up with messages like "bar: baz: foo(/data.txt): open: file not found". Debugging usually means for me replacing return err with a more verbose return fmt.Errorf("...: %v", err) and adding mentioned checks and/or additional log messages. Either with the log package or logrus. (And possibly adding unit tests/factoring out code into separate functions.) This gives me information content like in a full Java stack trace but in one line. But YMMV, probably it also depends what kind of software one writes.