Feedback Improve support for third party logging frameworks

It's possible to integrate third-party logging frameworks into a Unity project. For the most part, this works quite nicely. There are basically two aspects to this:

1. Set up the logging framework to forward logs to the Unity console, so that if you write CustomLog.Info("Something") it will appear on the Unity console, in addition to whatever other targets you define for the framework.
2. Hook into existing Debug.Log calls, so that they are forwarded to the new logging framework. Even if you can convert all your own log calls to the new framework, it's probably better not to change third-party code (e.g. SteamVR plugin), since it will be difficult to update in future. You just have to implement the ILogHandler interface and assign an instance to Debug.unityLogger.

Overall, this works quite nicely. But there are some issues within the Editor, when using your own log framework. Most of these are related to opening the correct line of code when double-clicking the logs in the Editor Console.

Because the last couple of frames on the stack trace are going to be functions from the custom logging framework, Unity will jump to an irrelevant line within the framework, instead of the correct Log call further down in the stack. This problem can mostly be solved by wrapping the custom logging framework in a managed plugin DLL, because Unity seems to skip source files that are not in the project.

Even if you wrap the logging into a plugin, the stack trace will still be spammed with irrelevant frames from the logging framework. For comparison, here is a nice and concise stack trace from a normal Debug.Log:



And here is the same log with a custom logging framework:



The entire highlighted part is noise. It doesn't matter if the stack trace type is set to Full or ScriptOnly. Unity considers the logging framework a script.

It is possible to completely disable the built-in stack traces of Unity with Application.SetStackTraceLogType, and printing a custom filtered stack trace instead, e.g. by using StackTraceUtility.ExtractStackTrace. However, this breaks the go-to-line on double-click behavior again. I assume Unity doesn't parse the stack trace when double clicking and instead just remembers the location when generating the stack trace the first time and if the stack traces are disabled, this doesn't work.

I think the most elegant solution would be to add an option to DLLs and assembly definitions to ignore them in the Console (stack trace + double click feature). This option would filter frames from these assemblies when Unity generates the stack trace for a log (the same it filters internal stuff in ScriptOnly mode). This may also fix the double click issue. All you would need to do to hook up a custom logging framework is to create a separate assembly definition for the glue code and mark it to be ignored in the Console.

Alternatively, Unity could provide a callback for us to implement to filter the generated stack traces. Any frame that we discard should not be printed and not be used for the double click feature.

An even more powerful solution would be a callback for the double click event. This would allow us to generate a custom stack trace, implement the default double click behavior or even add context-dependent actions.

 

This was discussed a few years ago on the beta-list, back when it was private. Their idea at this time was to decorate methods with an attribute to exclude those methods from appearing in a callstack. I provide an example of this here:
https://forum.unity.com/threads/edi...ts-double-click-message-functionality.623356/

 

Good idea! If this can be implemented in an efficient way, this is probably the most elegant solution.

I would probably call it [HideInStackTrace] or [HideInConsole] to be more consistent with [HideInInspector]

 

Good idea. Perhaps post the naming idea in the other thread, since Unity staff replied there already and is probably watching the thread too.

 

Was this ever implemented or worked on?
Did anything change, @benoitd_unity?

Should we create a new thread in the alpha or beta forums?


Previously, I was patching the StackTraceUtility.ExtractFormattedStackTrace method to have this functionality ad-hoc, but now the extracting of stacktraces is more involved and I can't patch it as before: StackTraceUtility.ExtractStackTrace will call Debug.ExtractStackTraceNoAlloc when possible instead of going through ExtractFormattedStackTrace only, and the Debug.ExtractStackTraceNoAlloc is extern, so I can't patch it.

Even with my "lean" logging framework, I still have an extra 7 lines of noise for every Debug.Log call.

 

Is this still being considered?

We tried implementing our own

ILogHandler

implementation, but the only way to let that implementation then forward the processed logs seems to be forwarding them to Unity's default handler (

Debug.unityLogger.logHandler

), which, in turn, appends our logger to the stacktrace.

The biggest downside is that crash analytics platforms, such as Firebase Crashlytics, will then group all crashes under one entry of our own ILogHandler, making them impossible to use.

 

@RobinBGbanga There seems to be a related entry on the Roadmap "under consideration". Maybe vote and comment on it there as well:

https://portal.productboard.com/z8pw2ms6jxytyez9chlmm4kr/c/527-console-window-improvements

 

Thanks for the nudge! I've left an upvote on that roadmap item.

 

It is a nice feature, thanks for getting it out there!


Sadly, there seems to be a bug around that might make this not work as expected for some users.
I posted about this earlier but didn't have free time to submit a bug report yet.

 

That's great news, thanks!

A follow-up question: will these methods only be hidden from the visual console window, or also from the actual callstacks?

Our concrete use-case is that we implemented a custom

ILogHandler

that unrolls inner exceptions the same as .Net (outermost first), rather than Unity's way (innermost first), but when the log handler forwards the processed stack to Unity's default log handler, that one always appends our custom log handler's method to the stack. Details in this thread. This has 2 downsides:

1. noise in the console window (this would be solved by your new feature, awesome!)
   
2. analytics services, such as Firebase Crashlytics, bundle all exceptions under the same node of our custom log handler

It would be great if case 2 could also be covered by this feature.
We're locked to 2021 LTS for our current project, but I'll give the 2022 alpha a shot separately as soon as I find the time!

 

Any chance this will be enhanced to actually filter out the final log file?
The amount of noise in the log files is immense, even using a very lean logging framework.
I previously used to patch Unity itself (in-memory) to accomplish this, and it was very nice to have clean, easy to follow logs. I mention this here: https://forum.unity.com/threads/imp...party-logging-frameworks.698942/#post-6518751

 

If that ever comes, the console part would be "free", since the console itself would never see the actual, unfiltered log.
The drawback is that there's no way to see this unfiltered log with a toggle. You would need to disable the filtering and trigger the initial log again to see it raw.
Despite that, it was still worthy it for me and is sorely missed.

 

I would love to see that, too! This would really help us a great deal.

 

@claudiaantoun just discovered [HideInCallstack] and was hyped! It is great and tidies up our console, because of custom logging tools which add 5 stack frames.

But, I was disappointed to see that it only removes the callstack lines from the detailed console view. Double clicking on a log entry still takes you to the line of code which generated the log. Double clicking on log entries is super helpful, but impossible for us because of the custom logging tool.

Any plans to support double clicking ignoring HideInCallstack methods?

It'd also be great if this attribute could be added to a class, which would ignore all methods in that class. This would avoid the need to add an attribute on every method in the class, as I want them all ignored

Cheers!

 

@claudiaantoun
I have a feeling my mention in the previous post didn't work as expected, so I'm trying again!

 

@claudiaantoun are updates on this?