Tracing code to pinpoint the source of issues

Another good client-side debugging practice is tracing, the practice of printing out key steps in the flow of a program. In a debugging scenario, this would consist of strategically making calls to the println (or fmt.Println) function around suspected areas of problematic code. You can use the web browser's console to verify that these print statements are reached, which will give you a better understanding of how the client-side program is functioning while it is running.

For example, when debugging the issue introduced in the previous section, we can place the following println calls in the run function:

func run() {
//println("IGWEB Client Application")
println("Reached the run function")
// Fetch the template set
templateSetChannel := make(chan *isokit.TemplateSet)
funcMap := template.FuncMap{"rubyformat": templatefuncs.RubyDate, "unixformat": templatefuncs.UnixTime, "productionmode": templatefuncs.IsProduction}
go isokit.FetchTemplateBundleWithSuppliedFunctionMap(templateSetChannel, funcMap)
// ts := <-templateSetChannel
println("Value of template set received over templateSetChannel: ", <-templateSetChannel)
env := common.Env{}
// env.TemplateSet = ts
env.TemplateSet = nil
env.Window = dom.GetWindow()
env.Document = dom.GetWindow().Document()
env.PrimaryContent = env.Document.GetElementByID("primaryContent")
env.Location = env.Window.Location()
println("Value of template set: ", env.TemplateSet)
registerRoutes(&env)
initializePage(&env)
}

We performed tracing by printing key steps in the flow of the program, by making strategic println function calls. The first println call is used to verify that we reach the run function. The second println call is used to check the health of the template set that is returned to us from the template set channel. The third, and final println call, is used to check the health of the template set after we have completed prepped the env object by populating its fields.

Figure A3 shows the web console with the print statements displayed, along with the respective line number in the client.go source file where the println call was made:

Figure A3: The print statements displayed in the web console

From the tracing exercise, we can first verify that we have successfully reached the run function. Secondly, we can verify the health of the TemplateSet object received over the templateSetChannel by noticing that properties of the object appear (such as members, Funcs, and bundle). The third, and final print statement, also verifies the health of the TemplateSet object after the env object has been prepped. This print statement reveals the source of the problem by showing us that the TemplateSet object has not been initialized, since we don't see any of the properties of the object appear in the printed statement.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.141.7.240