Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

builtin: trace function #6069

Closed
eaigner opened this issue Aug 7, 2013 · 4 comments
Closed

builtin: trace function #6069

eaigner opened this issue Aug 7, 2013 · 4 comments
Milestone

Comments

@eaigner
Copy link
Contributor

@eaigner eaigner commented Aug 7, 2013

I often need to see what's really going on in a specific function, so I drop a quick
`fmt.Println` in the code to output the data I want to investigate.

This has 2 disadvantages:

1) I always need to jump to the header and import "fmt" and remove it when the
log is removed
2) If I need more context information, I also have to import "runtime" to get
a call stack trace

I propose a built in function

    trace(args...interface{})

and/or

    tracef(format string, args...interface{})

that does this without requiring fmt or runtime. The output would look like the `panic`
stack trace with the custom information attached.
@eaigner
Copy link
Contributor Author

@eaigner eaigner commented Aug 7, 2013

Comment 1:

Essentially it's a panic that doesn't panic, just print.

@cznic
Copy link
Contributor

@cznic cznic commented Aug 7, 2013

Comment 2:

No need to put _into the_ language a new built-int for what can be _expressed by the_
language already. #Reject
----
package foo_test
import (
        "fmt"
        "path"
        "runtime"
)
func trace(s string, va ...interface{}) {
        _, fn, fl, _ := runtime.Caller(1)
        fmt.Printf("%s:%d: ", path.Base(fn), fl)
        fmt.Printf(s, va...)
        fmt.Println()
}
----
- Now you can write debug prints, to be printed during tests, like
    trace("%v %i", myVar, i)
- No need to import/unimport anything.
- You cannot forget to remove the debug prints before building the binary, because as
long as they are present in the source, the build will fail. It will build only when
doing
    $ go test

@eaigner
Copy link
Contributor Author

@eaigner eaigner commented Aug 7, 2013

Comment 3:

a) this solution only works provided that you are in a test case
b) you'll have to duplicate this for every package if you don't want explicit imports
So it's not a solution.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Aug 7, 2013

Comment 4:

print and println aren't even part of the language.  I don't think we need more stuff
that's debug-related.

Status changed to WorkingAsIntended.

@rsc rsc added this to the Go1.2 milestone Apr 14, 2015
@rsc rsc removed the go1.2maybe label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants