Why and how to use debugger with GO
The time we need to fix any issue depends on stage where it is found:
The earliest way to fix any issue — fix it before any code is written (on planning stage).
But if we already have bug in code, it'd be better to deal with it at the development stage.
So, the earlier we fix bug, the more efficient we are as developer and and as a team.
Debugger is extremely helpful here.
It is very common tool in many programming languages, but to me it seems that GO developers are not using it.
I will describe why it is helpful and why i recommend to use it by an examples in Goland IDE
What is debugger?
Debugger is all about breakpoints.
You set up points where you want your program to stop, so you will be able to monitor program state.
First, you set up breakpoint:
The program will stop _before_ line you selected.
Next, you run your program/test and it stops:
In the left side of debug toolbar you can see stack trace (all functions called before breakpoint is reached).
This trace is very informative if you explore new repo and want to understand if particular code executes and what are
other instructions involved.
Yeah, there is function usage tools in Goland. You can see all usage cases of any function,
but it can take a time, because you'll need to check many functions usage, until you find main.go.
Debugger just prints you full trace.
In the right side you can see any variables that are accessible in the scope of breakpoint.
On the left toolbar there are buttons to move between breakpoints.
Why one should use debugger?
1. No code modifications
To see what is happening in program, you don't need to add any
debug code (fmt.Print and etc).
If you choose to add debug code, this code will be located at the same files you want to debug,
so it will be all possible files of project. So there is no way to split up what code is for debug and what is for production.
You'll have to check any changes you made with your eyes before commit to find and remove debug code.
And even after that there is a huge probability to push debug code to repo (which will be a mistake you don't want to happen).
2. Simple way to explore any kind of variable
Debugger variables view is also much more user friendly than any output you can program to list variables.
For example, look how simple you can view any complex structs or lists:
You can see byte array, created from string, also you can see it as text by clicking "View" link.
How many time will you spend trying to display that data?
It will not be one line of code and that code depends
on variable type you want to explore.
Debugger displays any variable gracefully.
Minuses
Debugger changes the behaviour of program.
GO is known by it's concurrency patterns, so probably you have a lot of
goroutines in your program.
Breakpoint is set in code, that relates to one or some of all goroutines,
but what is happening in other goroutines is responsibility of debugger.
In Goland all goroutines are stopped.
But probably there can be a situation when you want to collect debug data,
but don't want program to stop. In that case you'll still need to get this debug info without debugger.
That is basically all on current topic.
Feel free to comment this Post here on website, or join our telegram group.