Printing an error type should print result of `.Error()`

[go-delve]

Printing an error type should print result of `.Error()`

[kostya-sh]

@derekparker, I think more general functionality to display a variable as fmt.Sprintf("%s", x) or fmt.Sprintf("%v", x) would be quite useful in cases when x is a big.Int or a big.Rat or any other user type with nice String() implementation.

May be a new command can be introduced for this: pf "format spec like %s, %d" s d

Dealing with breakpoints inside String() or Error() methods might be a bit tricky though.

[derekparker]

@binary132 Ah, I understand what you're saying. Makes sense.

[Omie]

I explored code a little for this. If nobody is working on variable printing then I'd like to take this up next.

It will require thinking a bit since there are more of similar type in line [ #61 #116 #117 #122 ]

Have you thought about how to go about this?

Should use a pretty printer package?
http://godoc.org/github.com/kr/pretty
https://github.com/davecgh/go-spew

It can get really messy if we think of all of these together.
package.ExportedSliceOfMap[index][key].MemberStruct.MemberSlice[index] is kind of scary.
Should this be thought of?

[aarzilli]

I've thought a bit about this and IMHO the optimal way to do this is in three steps

1. split the code in variables to separate calculation of addresses with reading values, this will help with step 3 and also make implementing a set command possible
2. change the code that reads values to read them into some data structure instead of producing a string directly, then implement a pretty printer on top of that
3. once 1 and 2 are in place use go/parser.ParseExpr to parse expressions and write an interpreter for (a subset of) the go expression sublanguage.

Printing the value of an expression like that would then be automatic. AFAIK you won't be able to use a pretty printer because those use reflect that's not going to work across processes.
I have step 1 almost done but I've been holding off publishing it because it depends on my other two PRs.

[derekparker]

@aarzilli you're correct and that sounds like a reasonable plan for the other issues mentioned by @Omie. This issue does not deal with evaluation based off of an expression, it involves adding functionality to call a Go function and store the return value(s) and then essentially print the string that is returned by .Error to the screen.

[derekparker]

@kostya-sh are you thinking of trying to use the format string and have Delve eval the variables used and then create the formatted string itself? That's kind of interesting, and could lead to the type of command you've suggested. Either way, we're still going to need to land #119 eventually before 1.0 and it would be nice to just be able to use that to "call" the Error method and read the string that it returns.

[kostya-sh]

@derekparker, no, my example of a new command wasn't very clear. s and d are names of local variables there, they could have been foo and bar. I wasn't aware of #119. With function calls one can just write:

fmt.Sprintf("format spec like %s, %d", foo, bar)

making a new command unnecessary.

[gideondsouza]

it's been a while here. Is this issue still open? I'm not an expert, I only recently started using go.

I would love to take this up, could someone just give me a few pointers about where to start digging at the source?

[aarzilli]

@gideondsouza you would have to first implement function calls, the problem there is interacting with the go runtime in a way that isn't fragile and doesn't upset the runtime: figure out how if there is enough stack space, extend the stack if there isn't enough for the call, deal with panics caused by the injected call, figure out how to make the garbage collector happy about a stack frame that would normally be impossible.

[binary132]

As a user, I'd really prefer to see the value of the error if I'm step-through debugging / tracing. Maybe this should be some kind of "alternate" print command, like "render" or "format"? (That could also be useful for rendering things like byte buffers, maybe using spew.Dump?)

[derekparker]

@binary132 I'm not sure I completely understand what you mean. The string returned from .Error() should be the formatted value of that error.

[binary132]

Yes, print err.Error() should print that string, but print err should show the value of the interface.

If I had my pick, I'd take what @kostya-sh suggested. If forced to choose between print displaying an interface's value or its String() result, I would definitely rather see the real value (plus calling a method could cause side effects, allocations, etc. which print should be expected not to trigger implicitly.)

[derekparker]

Going to close this out as technically this is possible now. You can execute call err.Error() and get the string back.