getsentry
Split logging integration from error capturing
We switched from hooking into Application.logMessageReceived to setting ourselves up as a loghandler via Debug.unitylogger.logHandler = this;
This also means that we have to format the message ourselves which has a non-insignificant impact on performance
We switched from Application.logMessageReceived to Debug.unitylogger.logHandler to get access to the actual exception object to hand that to the IL2CPP backend to provide line number support for caught and uncaught exceptions. We previously had our own string parsing functionality to turn the string stacktrace into a SentryStacktrace.
Maybe we can split this into two? Keep relying on the unitylogger for actual exceptions but set up the Application.logMessageReceived so that messages at least get a stacktrace (even without linenumbers for now). What do you think @munkiki7?
@bitsandfoxes , if Debug.unitylogger.logHandler is only actually useful for getting the exception, and is heavier in performance, then sure, we can only use it in that one place.
Is there any conclusion to this discussion? Can we use the method of monitoring Application.logMessageReceived instead of using Debug.unitylogger.logHandler = this;
Because there will be an extra line of useless information in the printed stack information: Sentry.Unity.Integrations.UnityLogHandlerIntegration:LogFormat(LogType, Object, String, Object[])
This is a very bad experience
