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

Not yet. But I'd really like to see this happen.

We've not forgotten about this and have it on the roadmap.