2

My aim is to create a logging function that lists the name of a function and the list of passed parameters.

An example would be the following:

func MyFunc(a string, b int){

   ... some code ...

   if err != nil{
       errorDescription := myLoggingFunction(err)
       fmt.Println(errorDescription)
   }

}

func main(){
   MyFunc("hello", 42)
}

// where MyLoggingFunction should return something like:   
// "MyFunc: a = hello, b = 42, receivedError = "dummy error description"

So far it seems that in Go there is no way to get the name of the parameters of a function at runtime, as answered in this question, but I could give up this feature.

I've managed to get the function name and the memory address of the passed parameters by analysing the stack trace, but I'm hitting a wall when it comes to print somehow the parameters starting from their address (I understand that it might not be trivial depending on the type of the parameters, but even something very simple will do for now)

This is an implementation of the logging function I'm building (you can test it on this playground), is there away to print the parameter values?

func MyLoggingFunction(err error) string {
    callersPCs := make([]uintptr, 10)
    n := runtime.Callers(2, callersPCs) //skip first 2 entries, (Callers, GetStackTrace)
    callersPCs = callersPCs[:n]

    b := make([]byte, 1000)
    runtime.Stack(b, false)

    stackString := string(b)

    frames := runtime.CallersFrames(callersPCs) 
    frame, _ := frames.Next()

    trimmedString := strings.Split(strings.Split(stackString, "(")[2], ")")[0]
    trimmedString = strings.Replace(trimmedString, " ", "", -1)
    parametersPointers := strings.Split(trimmedString, ",")

    return fmt.Sprintf("Name: %s \nParameters: %s \nReceived Error: %s", frame.Function, parametersPointers, err.Error())
}

If there are other ideas for building such logging function without analysing the stack trace, except the one that consists in passing a map[string]interface{} containing all the passed parameter names as keys and their values as values (that is my current implementation and is tedious since I'd like to log errors very often), I'd be glad to read them.

Dave C
  • 7,729
  • 4
  • 49
  • 65
dev_mush
  • 2,136
  • 3
  • 22
  • 38
  • 1
    Best advice might be: Don't do that. Ints and strings are harmless but how do you log a [1024][1024]complex128? Whats wrong with a non-magical solution where you actually write the log statement? – Volker Aug 23 '18 at 14:45
  • Nothing's wrong, it's just really tedious to write down all the parameters when you want to log. You get a lot of this error boilerplate code for something that often can be handled with the runtime environment of the language you're using in just a line of code, making the readability easier. That said, if it's not idiomatic or impossible I won't force things. – dev_mush Aug 23 '18 at 14:53
  • also, in my context, I mostly get json encodable parameters from client rpc calls, so although your objection is 100% correct, It's very unlikely that I'll find myself logging a [1024][1024]complex128 (and curious on when and how did you use it :D) – dev_mush Aug 23 '18 at 14:57
  • 1
    If you really need it you can try to write code generating tool. Basewords are: go generate, go/ast. – n-canter Aug 23 '18 at 15:15
  • yeah, I'll look into it, it was my "final straw" option – dev_mush Aug 23 '18 at 15:36

0 Answers0