We wrote our own custom logger which is a wrapper for Debug.Log() and we currently have to use it in a .dll form so that the wrapper itself does not appear in the console stack trace. This is so that when we double-click on a console log we are taken directly to the proper script/line instead of landing in the logger code itself.
Which is kind of a hack.
What we would need instead is a custom method attribute called (for example) “HideInStackTrace” in order to simply exclude a method from the console stack trace.
Needless to say, double-clicking on the log itself would send the user to the script/line that called the method (not the “hidden” method itself).
Something like this:
[HideInStackTrace]
public void MyCustomLogger(string _message)
{
...
}
(By the way, we do know about the callback to catch when something is logged ( Excluding a method frame from stack trace in Debug.Log()? ) but that doesn’t give us what we need as this only gets us the log content but has no effects on what the console actually shows)
Clearly, it only works for the editor though, so if you want something like that in custom log files then you’d need to register a custom callback for Application.logMessageReceived, but I’ve never tried that myself.
This would be really helpful for me, because I use/make C# libraries that might have a dependency on NLog for example.
If I want the library to work in my Unity project, I can write a custom target to output to the UnityEngine.Debug.LogXXX methods, but it has all these NLog methods in the stacktrace that I don’t care about.
However, there might be hope coming soon for this feature in a year or two?
I found this on Unity’s Editor roadmap, under the “Under Consideration” section at the time of writing today:
We added a new attribute, HideInCallstackAttribute, that you can use to exclude a method from the console stack trace. Here is the documentation for that attribute: Unity - Scripting API: HideInCallstackAttribute
Ooh, thanks for sharing!
This is very helpful and the docs page is great with the explanation and code example.
The only thing is I wish it could take in a bool to also apply its effect to any methods called recursively underneath the method that I mark as [HideInCallstack].
For example, if I’m calling into some logging class I made, which calls NLog, I can apply [HideInCallstack] to my logging method, but I’ll still see all the details of NLog’s method calls that I don’t want to see. Maybe a bool recursive parameter or something, where I could write [HideInCallstack(recursive: true)] would solve this
The only thing is that I wish it could accept a bool so that it would also affect any recursively called methods below the method I mark as [HideInCallstack]. backrooms game
That’s cool, although I wish you’d used the standard one instead. Such attributes can usually be redeclared without conflict (like we used to inject ExtensionMethodAttribute in old .NET versions).
This is handy, but is there a way to have this also so when you double click on the entry in the console, it doesn’t take you to that method if it had [HideInCallstackAttribute]. We are usually using this for debugging with custom print methods, so its not useful for the double click in the console to open up the Hidden print method.
That attribute doesn’t work for me, if implemented exactly as the example given in the APi doc. What gives?
Neither the callstack is filtered, nor does double-click take me to the highest expected point in the callstack, it takes me to the very debug log line.
Don’t forget to enable call stack stripping in the console options. Seems to work as of 2022.2.21.
For usability this feature should absolutely bring you to the correct line in editor when double-clicking. Seems to me than everyone looking for this feature is being a bit deceived.
and the docs page is great with the explanation and code example.
