log_warnings and log_errors displaying "eval" as function instead of function that led to error

[gabesolomon10]

I'm experiencing an issue of not seeing the correct displayed "function" when using

logger::log_warnings()
logger::log_errors()

I'm using the standard json formatter (formatter_json), and when errors/warnings occur inside of functions I've written, it would be great if the json "fn" field could include which function exactly led to the error/warning. Right now, I'm seeing for all of these that the json log outputs is for example:

{"time":"2020-10-05 12:09:48","level":"WARN","ns":"base","topenv":"base","fn":"eval","msg":"DE Opimization improved within 50 iterations of the max"}

It would be super helpful to have this JSON evaluate the "fn" field as the actual function (instead of "eval") which called the warning for meta-analysis of which functions in my code are leading to errors/warnings. Thanks!

[daroczig]

Thanks, this is a great idea! Passing down the calling fn name so that it can become available as a standalone variable in the JSON layout seems to be a bit tricky, so I wonder if you would be OK by prefixing the actual error/warning message with the calling function's name (as in the string)?

[gabesolomon10]

Ah, gotcha. It does seem to be a bit tricky from my brief attempts at it using sys.calls.

Do you mean I could prefix the error warning message like this? stop("Error in my_function_name: this function is broken")

That's a good idea and would be helpful for functions where errors are expected, but it wouldn't fully cover errors that are unexpected or that come from functions I haven't written. But if it's too tricky to globally pass down the calling fn name, then prefixing the error/warning message is definitely a good start. Appreciate the help.

[daroczig]

Actually, passing the caller fn is pretty straightforward -- could you please test #146?