TraceInfo Function Panics If Tracing Is Not Enabled

[JonnyPillar]

Hi, I came across an issue today where TraceInfo() panics when called and EnableTracing has been called. (Version v2.1.0)

Example based on SimpleGet (https://play.golang.org/p/n1EvoADpC3P)

	client := resty.New()

	resp, err := client.R().
		Get("https://httpbin.org/get")
...
	ti := resp.Request.TraceInfo()
	fmt.Println("DNSLookup    :", ti.DNSLookup)

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0xffffffff addr=0x0 pc=0x3b229a]

goroutine 1 [running]:
github.com/go-resty/resty/v2.(*Request).TraceInfo(0x896240, 0x80c110, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
	/tmp/gopath455282213/pkg/mod/github.com/go-resty/resty/v2@v2.1.0/request.go:533 +0x7a
main.main()
	/tmp/sandbox271512670/prog.go:28 +0x840

Running with EnableTrace wont panic (As expected)

	client := resty.New()

	resp, err := client.R().
		EnableTrace().
		Get("https://httpbin.org/get")
...
	ti := resp.Request.TraceInfo()
	fmt.Println("DNSLookup    :", ti.DNSLookup)

Request Trace Info:
DNSLookup    : 0s

This might be intentional behaviour but a simple nil check and maybe returning an error would be a cleaner solution and provide more control to the calling application.

Thought I would ask and happy to add a fix if needed 🙂

Thanks

[jeevatkm]

@JonnyPillar Thank you. You're correct I have kept it intentionally. Also, I agree with you having a nil check. Please feel free to send PR, appreciated 😄

My suggestion is to return an empty trace info object instead of the error.

[JonnyPillar]

@jeevatkm Agreed. No need to change the API then. Will get the PR to you soon