Search Unity

  1. Looking for a job or to hire someone for a project? Check out the re-opened job forums.
    Dismiss Notice
  2. Unity 2020 LTS & Unity 2021.1 have been released.
    Dismiss Notice
  3. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Feedback Improve support for third party logging frameworks

Discussion in 'Editor & General Support' started by DrummerB, Jun 21, 2019.

  1. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    106
    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.
     

    Attached Files:

  2. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,579
  3. DrummerB

    DrummerB

    Joined:
    Dec 19, 2013
    Posts:
    106
    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]
     
  4. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    5,579
    Good idea. Perhaps post the naming idea in the other thread, since Unity staff replied there already and is probably watching the thread too.
     
  5. SugoiDev

    SugoiDev

    Joined:
    Mar 27, 2013
    Posts:
    345
    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.
     
unityunity